Universidad Dr. José Matías Delgado Facultad de Economía Dr. Santiago I. Barberena Carrera Computación

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Universidad Dr. José Matías Delgado Facultad de Economía Dr. Santiago I. Barberena Carrera Computación"

Transcripción

1 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 ASPECTOS TEÓRICOS FUNDAMENTALES ORIGEN DE LA INFORMACIÓN CONCEPTO DE INFORMÁTICA TECNOLOGÍA DE INFORMACIÓN CONCEPTO GESTIÓN ARQUITECTURA SISTEMAS DE INFORMACIÓN CONCEPTO TIPOS CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN Modelo de cascada Modelo de construcción de prototipos Modelo evolutivo Modelo de desarrollo rápido de aplicaciones Modelo de métodos formales UML Concepto Origen Utilización Principales diagramas ANÁLISIS DE SISTEMAS DISEÑO DE SISTEMAS WORKFLOW Y LA INFORMÁTICA TECNOLOGÍA DE WORKFLOW ANTECEDENTES CONCEPTO DE WORKFLOW BENEFICIOS DE IMPLANTAR WORKFLOW COMPONENTES DE UN WORKFLOW SISTEMAS DE ADMINISTRACIÓN DE WORKFLOW CONCEPTO CARACTERÍSTICAS MODELO DE REFERENCIA DE WORKFLOW EJECUCIÓN DE UN WORKFLOW Tratamiento de los procesos Tratamiento de la organización TIPOS DE WORKFLOW Según su alcance Según el tipo de proceso o estructura de las tareas Según la tecnología que lo soporta RELACIÓN DE WORKFLOW CON OTRAS TECNOLOGÍAS

3 3 ANÁLISIS DE WORKFLOW FUNDAMENTOS METODOLOGÍA ESTUDIO PRELIMINAR Presentación de la organización Descripción del entorno Definición de las métricas MODELADO DE PROCESOS Selección del método Modelado del proceso actual Modelado del proceso meta VALIDACIÓN Métodos de validación Validación del proceso actual Validación del proceso meta INSTRUMENTOS DIAGRAMA DE ENTORNO DIAGRAMA DE PROCESO CASO PRÁCTICO: MODELADO BÁSICO PRESENTACIÓN DE LA ORGANIZACIÓN DESCRIPCIÓN DEL ENTORNO DEFINICIÓN DE MÉTRICAS DIAGRAMACIÓN DEL PROCESO VALIDACIÓN CASO PRÁCTICO: MODELADO AVANZADO CASO PRÁCTICO: VALIDACIÓN AUTOMATIZADA PRUEBAS DE CALIDAD DOCUMENTACIÓN ESTUDIO PRELIMINAR PROCESO ACTUAL PROCESO META LISTA DE VERIFICACIÓN PARA EL ANALISTA FACTORES DE ÉXITO PARA EL ANÁLISIS DISEÑO DEL SISTEMA FUNDAMENTOS METODOLOGÍA MODELADO DEL FLUJO DE TRABAJO Patrones de sincronización Discriminador Uniones N-de-M Múltiples instancias de una actividad Patrones basados en estado Selección diferida Encaminamiento paralelo alternado Patrones productor-consumidor Productor-consumidor con actividad de terminación Productor-consumidor con cola saturada MODELADO DE LOS ROLES MODELADO DE LAS SALIDAS REUTILIZABLES

4 Diagramación de los estados Diagramación de las transiciones MODELADO DE LOS PROCEDIMIENTOS PRUEBAS DE CALIDAD DOCUMENTACIÓN LISTA DE VERIFICACIÓN PARA EL DISEÑADOR FACTORES DE ÉXITO PARA EL DISEÑO CONSIDERACIONES Y RECOMENDACIONES INTEGRACIÓN DEL EQUIPO DE ANÁLISIS Y DISEÑO UTILIZACIÓN DE HERRAMIENTAS CASE IBM HOLOSOFX LOTUS WORKFLOW VARIACIONES AL MODELO DE ANÁLISIS Y DISEÑO BPM DIAGRAMA DE ESTADO ACTIVIDAD (DEA) Concepto Ejemplo GLOSARIO ANEXOS NOTACIÓN BÁSICA DE UML BIBLIOGRAFÍA

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: 5

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 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. 6

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 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 7

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 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 8

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 Concepto De acuerdo con la ANSI 1, 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 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). 9

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. 10

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. 11

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. 12

13 1.4.3 Ciclo de vida de los sistemas de información El ciclo de vida del desarrollo de sistemas (CVDS 2 ) 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 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 Ve el desarrollo de un sistema como una secuencia simple de fases en 2 Del ingles, software life cycle SWLC. 13

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. Procedende de la fase anterior A la fase posterior Documentos y productos de entrada Tareas propias de cada fase Validación del trabajo Replanificación y/o retroalimentación Documentos y productos de salida Experiencia acumulada Figura 1.1: Productos e insumos de las fases en un ciclo de vida de cascada 3 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,

15 Figura 1.2: Ciclo de vida de cascada 4 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,

16 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. Elaboración y revisión del prototipo Toma de requerimientos Prueba de prototipo Figura 1.3: Modelo de ciclo de vida de prototipos 5 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,

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 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 Este nombre fue utilizado posteriormente por la IEEE 6, en 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. 17

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,

19 Detalles de diseño. Implantación del código. Diversas pruebas. Planeación 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. 19

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 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. 20

21 1.4.4 UML 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. 21

22 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 Technique 9 ). Método propuesto por James Rumbaugh, enfocado en el análisis de sistemas. OOSE (Object-Oriented Software Engineering 10 ). 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 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. 22

23 desarrollo de un sistema: la toma de requerimientos, también conocido como el proceso de levantamiento 11 de requerimientos. Adicionalmente, cuenta con herramientas que pueden utilizarse para el análisis, diseño, implantación y prueba 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. 23

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 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 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? 24

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 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. 25

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. 26

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. 27

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. 28

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 miembros 12, 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. 29

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ón 13 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 30

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: 31

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 32

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 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 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: 33

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. 34

35 Las áreas funcionales anteriores pueden representarse con ayuda de la Figura 2.1: Tiempo de construcción Análisis de Proceso de Negocio, Modelado y Herramientas de Definición Definición y diseño del proceso Definición del proceso Tiempo de ejecución Instanciación y control del proceso Cambios al proceso Servicio de promulgación del workflow Interacción con usuarios y aplicaciones Aplicaciones y herramientas Figura 2.1: Características de un sistema de workflow 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,

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: Process Defination Tools Interface 1 Interface 5 Workflow API and Interchage formats Interface 4 Administration & Monitoring tools Workflow Enactment Services Workflow Engine(s) Workflow Engine(s) Interface 2 Workflow Client Applications Interface 3 Process Defination Invoked Tools Applications Figura 2.2: Modelo de referencia de workflow componentes e interfaces Ejecución de un workflow 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,

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. 37

38 Figura 2.3: Diferencia entre proceso y trabajo 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

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. 39

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

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 Tipos de workflow 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 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). 41

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. 42

43 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. 43

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. 44

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. 45

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. 46

47 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: 2 Diseño Análisis 1 3 Automatización Administración 4 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. 47

48 3.2 Metodología La metodología de análisis propuesta en este trabajo puede representarse con ayuda del siguiente diagrama: Estudio preliminar - Presentación de la organización - Descripción del entorno - Definición de las métricas Proceso actual - Modelado - Validación Proceso meta - Modelado - Validación 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 48

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 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. 49

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 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: 50

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 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. 51

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. 52

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 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). 53

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. 54

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. 55

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. 56

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 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 57

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: 58

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. 59

60 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. 60

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 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: 61

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 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 62

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 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 63

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 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. 64

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 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 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. 65

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 ) documentación de procesos. La plantilla propuesta se presenta en la Figura

67 Clientes del proceso Eventos iniciadores/entradas del proceso Subproceso Entregables/Salidas del proceso Unidades organizativas (Involucradas en el proceso) Entidades externas (Involucradas en el proceso) Figura 3.3: Plantilla de fronteras de procesos Diagrama de proceso Para diagramar el proceso (actual o meta) se sugiere utilizar el lenguaje gráfico propuesto por la empresa Holosofx 18. 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 Lanzando el Workflow BPR Versión 1 en 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 En 2001 HOLOSOFX introdujo su Suite BPM 4.1. BPM Suite comprende BPM Workbench, BPM Monitor, y el BPM Server. 67

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. 68

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. 69

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. 70

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. 71

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. 72

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 73

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. 74

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. 75

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 76

77 siete años, después de que las órdenes asociadas hayan sido entregadas o rechazadas 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: Procesos de Cliente 1. Clientes Externos 2. Empleados Disparadores/Entradas de procesos 1. Ordenes de Cliente 2. Ordenes de Venta Subprocesos 1. Ordenes de Cliente 2. Obtener Info. de Crédito 3. Revisión de Crédito Entregables/Salidas de Procesos 1. Orden de Trabajo 2. Notificación de Rechazo Unidades Organizativas (Involucradas en el proceso) Entidades Externas (Involucradas con el 1. Contabilidad y Administración proceso) 2. Ventas 1. Cliente 3. Compras 2. Agencia de Créditos Figura 3.4: Plantilla de fronteras del proceso caso de análisis. A 77

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 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. 78

79 Preparar Orden de Cliente Orden de Venta Línea de Crédito Disponible? Emitir Orden de Compra Orden de Trabajo No 20 Si 80 Orden de Venta Aceptada Orden de Venta 1 Aceptada Orden de Venta 2 Rechazada Obtener Info. de Crédito Orden de Ventas Orden de Venta 3 Rechazada Revisar Crédito Notificación de Cliente Rechazar Orden de Venta 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. 79

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. Tipo de Orden? Teléfono Orden Telefónica Crear Orden de Cliente Orden de Venta Emitir Orden de Trabajo Orden de Trabajo cliente B2B Orden B2B Registrar Orden de Cliente Orden de Venta B2C Orden B2C Traducir Orden de Cliente Orden de Venta Figura 3.6: Proceso Preparar Orden de Cliente 80

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 B2C 19, 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 B2B 20 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. 81

82 colocada y recibida utilizando programas orientados a la codificación y decodificación de mensajes comerciales, tales como EDI 21 o XML 22. 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). Orden de Venta Crear solicitud de Info. de Creditos Solicitud de crédito Preparar reporte de crédito Reporte de Crédito Actualizar Orden de Venta Orden de Venta Agencia de Crédito 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. 82

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. Orden de Venta Valuo de Crédito? Bajo Riesgo Orden de Venta 20 Aceptada Mediano Riesgo Revisar Perfil de Cliente Aprueba Crédito? Orden de Venta 60 No 50 Si 50 Aceptada Orden de Venta Rechazada Alto Riesgo Orden de Venta 20 Rechazada Figura 3.8: Proceso Revisión de Crédito Las tareas del proceso han sido descritas con ayuda de la siguiente tabla: Tarea Crear Orden de Cliente Registrar Orden de Cliente Traducir Orden de Cliente Emitir Orden de Trabajo Crear Solicitud de Info. de Créditos Unidad Organizacional Ventas Rol Procesador de ordenes Duración Total min. Trabajo Efectivo min. Ventas Sistema min s. Ventas Sistema min s. Despacho Despachador min min. Ventas Procesador de Ordenes hs min. 83

84 Actualizar Orden de Ventas Revisar Perfil de Cliente Rechazar Orden de Venta Ventas Contabilidad y Administración Procesador de Ordenes Gerente Contable min h min min. Despacho Despachador min min. 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 Incidencia /Opción (%) Bajo Riesgo 20 Mediano 60 Riesgo Alto Riesgo 20 teléfono 25 B2B 45 B2C 30 Línea de 80% (Si) crédito 20% (No) disponible? Esta aprobado 50% (Si) el crédito? 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. 84

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 m Crear Orden de Cliente Emitir Orden de Trabajo Correo Interno de h Oficina Actualizar Orden de Venta Revisar Perfil de Cliente Correo Interno de h Oficina Especificaciones de los medios del proceso Ordenes de Venta 85

86 3.4.5 Validación A efecto de demostrar los beneficios del nuevo proceso 23, 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 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% 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. 86

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 meta 25. 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. 87

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: 88

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. Crear Solicitud Solicitud del cliente Investigar Solicitud Solicitud de Cliente Investigada Crear Respuesta Respuesta para Cliente Revisar Respuesta Respuesta para Cliente Revisada 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

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. 90

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). 91

92 Crear Solicitud Solicitud del cliente Investigación Necesaria Investigación no Necesaria Investigación de Desarrollo Investigación de Mercadeo Crear Respuesta con Información Disponible Solicitud de Cliente Investigada Integración de Investigaciones F Solicitud de Cliente Investigada Respuesta para Cliente Crear Respuesta Respuesta para Cliente Integración Consolidada Revisar Respuesta Respuesta para Cliente Revisada 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

93 hasta que el supervisor dé el visto bueno a la respuesta redactada (ver Figura 3.11). Crear Solicitud Solicitud del cliente Investigación Necesaria Investigación no Necesaria Investigación de Desarrollo Investigación de Mercadeo Crear Respuesta con Información Disponible Solicitud de Cliente Investigada Integración de Investigaciones F Solicitud de Cliente Investigada Respuesta para Cliente Crear Respuesta Respuesta para Cliente No Integración Consolidada Revisar Respuesta Si Respuesta para Cliente Revisada Corregir Respuesta Respuesta para Cliente Figura 3.11: Depuración del proceso Solicitudes de Cliente (Reclamos) 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

94 Figura 3.12: Proceso Empaque de Ordenes de Trabajos. Las actividades representadas fueron documentadas con los siguientes datos: Actividad Unidad Organizativa Puesto Días de Días Duración Trabajados Determinar Tipo de Empaque Bodega Asistente de Bodega Empaque (cartón) Empacado Asistente de Bodega Ensamblar (caja de madera) Empacado Asistente de Bodega 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: 94

95 Nombre de Caso del Proceso Tesis \ Reporte: Tiempos de Casos del Proceso Porcentaje Tiempo de Proceso Tiempo de Transferencia Tiempo de Espera Tiempo de Trabajo Caso d 0.08d 0.06d 0.01d Caso d 0.04d 0.01d 0.09d Promedio Ponderado d 0.07d 0.04d 0.04d 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 95

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. 96

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 El siguiente histograma muestra los resultados obtenidos: Límite inferior L especificado Límite superior especificado 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 97

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 98

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 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 Esta sección contiene los objetivos y metas del proyecto. Deben presentarse tal como se encuentren especificados en los documentos Objetivo Establecer un marco de referencia 99

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. Sección 1.2: Motivadores de cambio Ordenados y clasificados según su área de impacto. Responsable Analista de Negocio Objetivo Establecer un marco de referencia Responsable Analista de Negocio Sección 1.3: Delimitación del proceso 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. Objetivo Establecer un marco de referencia Responsable Analista de Sistema 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: 100

101 Capítulo 2: PROCESO ACTUAL Sección 2.1: Modelo Diagrama del proceso tal como se encuentra implantado en la organización. Es necesario que cada elemento representado incluya los siguientes datos: Objetivo Presentar el proceso a través de un lenguaje visual Elemento Tarea Salida reutilizable Conector Decisión Opción Fusión Ir a Especificaciones Nombre Unidad organizativa Roles Duración Trabajo efectivo Espera Recursos utilizados Nombre Estado Medio que representa Tiempo de transferencia Actividad origen Actividad destino Nombre Tipo (binaria, múltiple) Modalidad de bifurcación Nombre Oportunidad de selección (%) Nombre Modalidad de fusión Tarea destino Descripción Responsable Analista de Sistemas 101

102 Entidad externa Proceso externo Nombre Nombre Entidad externa Duración Sección 2.2: Validación 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. Objetivo Presentar los promedios obtenidos y los resultados de las simulaciones Responsable Analista de Sistemas 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 Diagrama del proceso tal como se espera implantar en la organización. Es necesario que cada elemento representado incluya los siguientes datos: Objetivo Presentar el proceso a través de un lenguaje visual Documentar las especificaciones para el diseño del workflow 102

103 Elemento Tarea Salida reutilizable Conector Decisión Opción Fusión Ir a Especificaciones 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. Nombre Estado Datos que contiene Medio que representa Tiempo de transferencia Actividad origen Actividad destino Nombre Tipo (binaria, múltiple) Datos utilizados Fórmulas de evaluación Modalidad de bifurcación Nombre Oportunidad de selección (%) Nombre Modalidad de fusión Tarea destino Descripción Responsable Analista de Sistemas 103

104 Entidad externa Proceso externo Nombre Nombre Entidad externa Duración Sección 3.2: Validación 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 Entradas Detalle Indica el contenido de las distintas entradas que se utilizarán en el escenario. Objetivo Presentar los promedios obtenidos y los resultados de las simulaciones Responsable Analista de Sistemas Recursos Tiempos Medios Enumera cada una de las tareas que constituyen el proceso con los recursos que se le asignarán. Especifica las duraciones, trabajo efectivo y espera de las distintas actividades. 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. 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. 104

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 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 Instrumentos 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 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. Instrumentos Entrevistas Encuestas Recolección de documentos Herramientas Aplicaciones de oficina Entregable Perfil de la empresa Actividad: Descripción del entorno El Analista de Sistemas buscará delimitar el proceso en el cual se trabajará, estableciendo fronteras de inicio y finalización. Instrumentos Diagrama de entorno Herramientas 105

106 Aplicaciones de oficina Entregable Diagrama de entorno Actividad: Definición de métricas 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. Instrumentos No aplica Herramientas Aplicaciones de oficina Entregable Lista de indicadores y niveles esperados ANÁLISIS DEL PROCESO ACTUAL Actividad: Modelado 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 Instrumentos Lenguaje de modelado Herramientas Aplicaciones de oficina Modelador de procesos Entregable Diagrama de proceso Control de calidad Verificación sintáctica Actividad: Validación 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 Instrumentos Promedios ponderados Simulación Histograma de variación Herramientas Aplicaciones de oficina Modelador de procesos 106

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 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. Instrumentos Lenguaje de modelado Herramientas Aplicaciones de oficina Modelador de procesos Entregable Diagrama de proceso Control de calidad Verificación sintáctica Actividad: Validación 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 Instrumentos Promedios ponderados Simulación Histograma de variación Herramientas Aplicaciones de oficina Modelador de procesos Entregable 107

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. 108

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. 109

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. 110

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: 111

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. 112

113 Aplicaciones Objetos de Negocio Objetos de Proceso Persistencia 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 desarrollo 30. 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, y US$75,000.00, dependiendo si generan modelos propietarios o estándares, siendo estas ultimas las más caras. 113

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: Modelado del flujo de trabajo - Identificación de patrones - Diagramación de actividades Modelado de los roles - Diagramación de swimlanes Modelado de las salidas reutilizables - Diagramación de estados - Diagramación de transiciones Modelado de los procedimientos - Diagramación de secuencias 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 114

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 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 workflow 31, 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 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. 115

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: 116

117 Modificaciones necesarias para aplicar el patrón. Modelo UML asociado 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 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 117

118 entrega el resultado la ejecución del flujo continua. El segundo resultado es ignorado. Base de datos Resultado Internet Resultado Base de datos Consulta consulta Figura 4.4: Consulta por internet utilizando un patrón discriminador 32. En la mayoría de los WFMS, el discriminador no puede ser modelado a nivel conceptual 33. Una excepción notable es Verve 34, que ofrece un constructo 35 específico para este patrón. En el workflow de SAP R/3 36 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 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, Accessed March 2001 from 34 ver sitio http//www.verve.com ó 35 Elemento sintáctico para la creación de modelos. 36 ver sitio 118

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

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. Discriminador (a) Descripción Informal (b) Expresado como un diagrama de actividad de UML 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

121 Modelo UML asociado Esperar investigación informe Crear respuesta Investigación de Desarrollo /enviar informe Solicitud de cliente Informe de Mercadeo Respuesta Investigación de Mercadeo /enviar informe Informe de Mercadeo Figura 4.7: Utilización del discriminador para representar la creación de una respuesta que depende de un solo informe Uniones N-de-M También es conocida con el nombre de Unión Parcial 39. 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 Springer Verlag, December

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). Document paper o reviewer Revisor A reviewer Revisor B reviewer Revisor C 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

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

124 N := 2 i := 0 Esperar investigación informe[i < (N - 1)]/i := i + 1 informe [i < (N - 1)] Crear respuesta Investigación Desarrollo /enviar informe Informe de Desarrollo Solicitud de cliente Respuesta Investigación Mercadeo /enviar informe Informe de Mercadeo Investigación Ventas /enviar informe Informe de Ventas 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 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. 124

125 100 solicitantes Envíos concurrentes 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

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 Solicitud de * investigación del cliente Respuesta 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

127 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 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. 127

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: contrato Firmado OR Firmado + director secretaria director adjunto Figura 4.14 Contrato con firmas de responsable disponible Patrón Selección Diferida 44. 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

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 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

130 Modelo UML asociado Analizar solicitud Seleccionar investigación investigación de Desarrollo sin investigación investigación de Mercadeo Investigación de Desarrollo Investigación de Mercadeo Crear respuesta con información disponible 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. 130

131 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 A i (1 < i > n). En la rama que conduce a la actividad A 1, otra selección diferida es realizada (después de que A 1 ha sido ejecutada) entre n -1 ramas, iniciando con 131

132 A 2...,A n. Este proceso de selecciones diferidas anidadas es recursivamente repetido hasta que todas las permutaciones de A 1...,A n 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 A i hasta que se presente el evento que habilita la ejecución de la misma. Cuando A i 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. 132

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

134 Modelo UML asociado informe[i >1]/i := i - 1 i := 3 Esperar solicitud de prueba s1 s1/diferir s2/diferir informe[i = 1] s2 Prueba Laboratorio 1 /enviar informe Prueba Laboratorio 2 /enviar informe Figura 4.18: Utilización del encaminamiento paralelo alternado para representar de una respuesta 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 134

135 Productor-consumidor con cola saturada 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 135

136 disponibilidades han sido verificadas, se envía un correo con la lista de todos los productos disponibles y su tiempo de entrega. Orden de V3 artículos < Correo electrónico > V1 V2 V3 V4 customer comprobar disponibilidad de artículo plazo de entrega esperado No desea otro artículo Lista de productos disponibles Tiempo de entrega de productos 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

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 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia

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. 138

139 Modelo UML asociado Crear solicitud Esperar solicitud Esperar informe Investigar solicitud Crear respuesta Figura 4.21: Modelo para el procesamiento de solicitudes utilizando el patrón productorconsumidor con actividad de terminación 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. 139

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. aplicante Staff de oficina 5 sillas fotógrafo 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

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

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: Cliente Ventas Bodega Solicitudes Tomar orden Pago Llenar orden Reunir Orden Entregar orden 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

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 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. 143

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: Vacía Ítem agregado Validada Pago presentado Cancelada Método de pago falló En Proceso Procesada Pago exitoso Debitada a Inventario 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. 144

145 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. 145

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. Ingresar solicitud de materiales Solicitud de materiales Autorizar solicitud de materiales Solicitud de materiales autorizada Crear orden de compra 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

147 Orden [Orden B2B] [Orden telefónica] [Orden B2C] Procesar orden de empresa Procesar orden de cliente Digitar orden del cliente Orden de venta Revisar disponibilidad de crédito Orden de venta Obtener información del crédito (subproceso) Orden de venta [Línea de crédito no existe] [Línea de crédito existe] Revisar crédito (subproceso) Orden de venta [Crédito aprobado] Emitir orden de trabajo [Crédito rechazado] Rechazar orden de venta Orden de trabajo Notificación de rechazo Figura 4.27: Diagrama de actividad para el procesamiento de una orden de venta. 147

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

149 Reclamo Crear solicitud Solicitud de cliente Analizar solicitud Solicitud de cliente [Investigación de Desarrollo] [Investigación de Mercadeo] [Investigación no necesaria] Investigación de Desarrollo Investigación de Mercadeo Crear respuesta con información disponible Informe de Dearrollo Informe de Mercadeo Respuesta Revisar respuesta Consolidar investigaciones Respuesta Investigación Solicitud de cliente Crear respuesta con resultados de investigación Respuesta Figura 4.28: Diagrama de secuencia para la tramitación de un reclamo de cliente. 149

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: Solicitud de cliente [Investigación necesaria] Investigación de Desarrollo Investigación de Mercadeo Informe de Dearrollo Informe de Mercadeo Consolidar investigaciones Figura 4.29: Diagrama de secuencia parcial para representar investigaciones simultaneas. 150

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 UML A Beginner s Guide, Jason T. Roff,, Mc Graw Hill USA, primera edición

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). 152

153 Interfaz manual Catálogo de clientes Vendedor [orden telefónica] Digitar código de cliente Buscar cliente Devolver datos de cliente Solicitar datos al cliente [cliente existe] Inicializar orden de venta con datos de cliente devueltos Registrar cliente Devolver código de nuevo cliente Inicializar orden de venta con datos de cliente devueltos 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). 153

154 Interfaz manual Inventario Ordenes Vendedor Digitar código de artículo Buscar artículo Devolver datos de artículo Solicitar datos al cliente [artículo sin existencias] Cargar los datos del artículo en la orden de venta «crear» Notificar al usuario Buscar artículos sustitutos con existencias Cuadro de Mensajes Devolver artículos Mostrar artículos sustitutos Seleccionar artículo sustituto Cargar los datos del artículo sustituto en la orden de venta «destruir» X Totalizar la orden de venta Guardar la orden de venta * [mientras más artículos pedidos] 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 154

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: 155

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: 156

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: Responsable Ingeniero de sistemas Elemento Actividad Transición Especificaciones Nombre Descripción Diagrama de secuencia asociado Eventos Variables Guardas Capítulo 2: Modelado de Roles Sección 2.1: Diagramas de swimlanes 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: Responsable Ingeniero de sistemas Elemento Rol Especificaciones Nombre Descripción Actores potenciales 157

158 Capítulo 3: Diagramación de Salidas Reutilizables Sección 3.1: Diagramas de Estado Muestra la evolución que sigue un documento durante la ejecución del flujo de trabajo. Es necesario incluir los siguientes datos: Responsable Ingeniero de sistemas Elemento Estado Especificaciones Nombre Descripción Evento de transición Sección 3.2: Diagramas de Transición 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: Responsable Ingeniero de sistemas Elemento Transición de objeto Especificaciones Nombre Atributos Actividad de origen Actividad de destino Capítulo 4: Diagramación de Procedimientos Sección 4.1: Diagramación Secuencia Responsable 158

159 Especificación de los procedimientos utilizados por las actividades. Es necesario incluir los siguientes datos: Ingeniero de sistemas Elemento Mensaje Especificaciones Correlativo Descripción Estructura Tipo Actor/Objeto origen Actor/Objeto destino 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 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 Instrumentos Sesión de grupo Herramientas Aplicaciones de oficina Modelador de procesos Entregable Integración del equipo de desarrollo 159

160 MODELADO DEL SISTEMA Actividad: Creación de las especificaciones 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 Instrumentos 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. 160

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. 161

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. 162

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. 163

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. 164

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,

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 Holosofx 56 y Lotus Workflow 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. 166

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. 167

168 Se basa en una metodología denominada CBPM 57, 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 BPM 58, 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 Workflow 59, un sistema de administración de flujos de trabajo (WfMS) que también ha sido desarrollado por IBM. El workflow es exportado utilizando FDL 60, 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. 168

169 Figura 5.2: Fases de requeridas por MQSeries Workflow. 61 Las soluciones IBM Holosofx y MQSeries Workflow se encuentra basada tanto en estándares 62 de la industria y como en tecnologías propietarias 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 IBM es patrocinador de la WfMC. 169

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. Carpeta Portafolio Cubierta Documento principal Información relacionada con workflow Contenido principal del caso de negocio Documentos de carpeta Contenido adicional 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

171 Actividad A Persona A Tarea X Tarea Y Tarea Z Actividad B Persona B Tarea Q Tarea R Tarea S Actividad C Persona C Tarea K Tarea L Tarea M 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

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

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. Application Aplicación Directory Directorio Design Diseño Process Procesos 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

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. 174

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. Actividad 2. Modelado del entorno de trabajo 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. Descripción: En este modelo se genera un documento denominado: calendario. Este documento contiene la siguiente información: 175

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 176

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ón 177

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC.

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow Palabras claves: Groupware, Workflow, BPCM, WfMC. Introducción A partir de la llegada de las computadoras personales al ambiente empresarial

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

Visión General GXflow. Última actualización: 2009

Visión General GXflow. Última actualización: 2009 Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

Ingeniería de Negocios y Desarrollo de Sistemas de Información

Ingeniería de Negocios y Desarrollo de Sistemas de Información Ingeniería de Negocios y Desarrollo de Sistemas de Información Procesos de Negocios Modelos de negocio Ingeniería de Negocios: Notaciones Procedimientos Patrones Proceso de desarrollo de sistemas Metodologías

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Capítulo 1. Groupware. 1.1 Groupware y CSCW. Groupware

Capítulo 1. Groupware. 1.1 Groupware y CSCW. Groupware Capítulo 1 Groupware La cooperación y la colaboración en equipos de trabajo son esenciales para la competitividad y por lo tanto de la supervivencia de cualquier empresa. El trabajar juntos es un requisito

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Procesos de Negocios

Procesos de Negocios Procesos de Negocios Procesos de negocios Como dijimos en el Tema 1: los sistemas de información y las organizaciones se influyen entre sí: Los SI deben proveer la información que la organización necesita.

Más detalles

Workflow: Tecnología Para la Innovación Organizacional. Workflow: Tecnología Para la Innovación Organizacional

Workflow: Tecnología Para la Innovación Organizacional. Workflow: Tecnología Para la Innovación Organizacional Workflow: Tecnología Para la Innovación Organizacional Lic. Elizabeth Acosta Gonzaga Profesora del CIDETEC-IPN M. en C. Abraham Gordillo Mejia Profesor de UPIICSA-IPN L a búsqueda de mayor productividad

Más detalles

Herramientas Informáticas I. Software: Clasificación y Funcionalidad Facultad de Ciencias Económicas y Jurídicas Universidad Nacional de La Pampa

Herramientas Informáticas I. Software: Clasificación y Funcionalidad Facultad de Ciencias Económicas y Jurídicas Universidad Nacional de La Pampa Herramientas Informáticas I Software: Clasificación y Funcionalidad Facultad de Ciencias Económicas y Jurídicas Universidad Nacional de La Pampa 2013 Introducción La clasificación del Software permitirá

Más detalles

Boletín de Asesoría Gerencial* Business Process Management (BPM)

Boletín de Asesoría Gerencial* Business Process Management (BPM) Espiñeira, Sheldon y Asociados * No. 11-2009 *connectedthinking Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección

Más detalles

<TITULO DEL PROYECTO DE DESARROLLO DE SW > Diana Milena Pérez Riveros 1 Diana Milena Pérez Riveros Pagina de

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

S s i t s em a s de d Inf n o f r o m a ió i n TIPOS DE SISTEMAS

S s i t s em a s de d Inf n o f r o m a ió i n TIPOS DE SISTEMAS Sistemas de Información TIPOS DE SISTEMAS La Empresa en la Sociedad de la Información: Impacto en las Organizaciones TICS TICS - COMPONENTES el factor humano los contenidos de la información el equipamiento

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN

CAPÍTULO V PROPUESTA DE LA SOLUCIÓN CAPÍTULO V PROPUESTA DE LA SOLUCIÓN 5.1 Introducción En los últimos tres años la entidad financiera ha venido sufriendo cambios que le han permitido crecer y pasar de ser una Sociedad Financiera a un Banco

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

Diseño e Implementación de los Procesos de Gestión TI

Diseño e Implementación de los Procesos de Gestión TI Diseño e Implementación de los Procesos de Gestión TI Alumno(s): Año Académico: 2012 Profesor Guía: Contraparte: ALEJANDRO JESUS ARAVENA ORTIZ LORENA ANDREA ALBORNOZ POBLETE DANIEL HORMAZABAL Escuela de

Más detalles

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc).

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc). REVISIÓN CONCEPTOS, METODOLOGÍAS Y HERRAMIENTAS SOPORTE EN INGENIERÍA MARLON MÚJICA Estudiante de Ingeniería de Sistemas Universidad Industrial de Santander mujica@cidlisuis.org COLOMBIA EDWIN LOGREIRA

Más detalles

BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización

BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización Renato de Laurentiis Gianni Director IBERICA IT Group Introducción Cada vez más los Sistemas BPMS-Business Process

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

CAPÍTULO 1 Instrumentación Virtual

CAPÍTULO 1 Instrumentación Virtual CAPÍTULO 1 Instrumentación Virtual 1.1 Qué es Instrumentación Virtual? En las últimas décadas se han incrementado de manera considerable las aplicaciones que corren a través de redes debido al surgimiento

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: CICLO DE VIDA VISIÓN TRADICIONAL DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN STEMAS DE INFORMACIÓN Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza M. Material revisado

Más detalles

INGENIERIA DE SOFTWARE I INTRODUCCIÓN A LA INGENIERIA DE SOFTWARE

INGENIERIA DE SOFTWARE I INTRODUCCIÓN A LA INGENIERIA DE SOFTWARE INGENIERIA DE SOFTWARE I INTRODUCCIÓN A LA INGENIERIA DE SOFTWARE Agenda El software. Definición de software Dominios de aplicación Software heredado La naturaleza de las webapps Ingeniería del software

Más detalles

Desarrollo de aplicaciones para la sociedad de la información Bloque II- Dominios de aplicaciones sociales Tema 3- Gestión de procesos de negocio

Desarrollo de aplicaciones para la sociedad de la información Bloque II- Dominios de aplicaciones sociales Tema 3- Gestión de procesos de negocio Desarrollo de aplicaciones para la sociedad de la información Bloque II- Dominios de aplicaciones sociales Tema 3- Gestión de procesos de negocio Máster Universitario Oficial en Sistemas Telemáticos e

Más detalles

SISTEMAS DE INFORMACIÓN I TEORÍA

SISTEMAS DE INFORMACIÓN I TEORÍA CONTENIDO: TIPOS DE SI: SISTEMAS DE AUTOMATIZACIÓN DE OFICINAS, GROUPWARE, SISTEMA DE WORKFLOW Material diseñado y elaborado por: Prof. Anna Cecilia Grimán SISTEMAS DE AUTOMATIZACIÓN DE OFICINAS Los Sistemas

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes DESARROLLO DE SOFTWARE EMPRESARIAL Jonás Montilva C. Judith Barrios A. Universidad de Los Andes Desarrollo de Software Empresarial Derechos Reservados. Ninguna parte de este documento puede ser reproducida,

Más detalles

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje Escuela Universitaria de Ingeniería Industrial, Informática y Sistemas Área de Computación e Informática Universidad Tarapacá Arica Aplicaciones Web que Permitan Administrar Portafolios para Gestionar

Más detalles

Universidad Latinoamericana de Ciencia y Tecnología FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA INFORMÁTICA

Universidad Latinoamericana de Ciencia y Tecnología FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA INFORMÁTICA Universidad Latinoamericana de Ciencia y Tecnología FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA INFORMÁTICA Trabajo final para optar por el grado de Licenciatura en Ingeniería Informática con énfasis

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software Universidad de Colima Dirección General de Educación Superior Facultad de Ingeniería Mecánica y Eléctrica Licenciatura en Ingeniería en Sistemas Computacionales I. DATOS GENERALES P R O G R A M A A N A

Más detalles

PROCESOS INTELIGENTES

PROCESOS INTELIGENTES Su experiencia administrando documentos nunca será la misma!! Lo invitamos a descubrir una forma más fácil, rápida, segura y eficiente para gestionar su información corporativa relevante. www.valuetech.cl

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

M.T.I. Arturo López Saldiña

M.T.I. Arturo López Saldiña M.T.I. Arturo López Saldiña Hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas trabajen dentro de una organización de manera colaborativa. El problema se vuelve más difícil

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar 1 Definir el problema/oportunidad Definir problema de negocio o la oportunidad de mejora utilizando el pensamiento sistémico. Mapa Conceptual Desarrollar soluciones alternativas Seleccionar la solución

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

IMPLANTACIÓN DE UNA ESTRATEGIA DE GESTIÓN POR PROCESOS (BPM). Factores críticos de éxito y competencias profesionales necesarias.

IMPLANTACIÓN DE UNA ESTRATEGIA DE GESTIÓN POR PROCESOS (BPM). Factores críticos de éxito y competencias profesionales necesarias. IMPLANTACIÓN DE UNA ESTRATEGIA DE GESTIÓN POR PROCESOS (BPM). 1 Factores críticos de éxito y competencias profesionales necesarias. Objetivos generales del TFG Determinar cuales son los factores críticos

Más detalles

Trabajo de compilación bibliográfica Auditoria sistemas. Fernando Salazar Soto 1700421335. BPM "Business Process Management"

Trabajo de compilación bibliográfica Auditoria sistemas. Fernando Salazar Soto 1700421335. BPM Business Process Management Trabajo de compilación bibliográfica Auditoria sistemas Fernando Salazar Soto 1700421335 BPM "Business Process Management" Universidad De Caladas Facultad de Ingeniería Ingeniería de sistemas y computación

Más detalles

SOLUCIÓN SITUACIÓN ACTUAL

SOLUCIÓN SITUACIÓN ACTUAL SITUACIÓN ACTUAL La necesidad de las organizaciones de ser más competitivas en un mercado dinámico ha generado estructuras organizacionales complejas y exigentes en términos de calidad y eficiencia. Sobre

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA)

MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) Nelson Beltran Galvis Grupo de Investigación de Ingeniería de Software, Universidad Francisco de Paula Santander.

Más detalles

Gestión de Procesos de Negocios BPM

Gestión de Procesos de Negocios BPM GNU/LinuX Universidad Inca Garcilaso de la Vega XLIX CURSO DE ACTUALIZACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS Y CÓMPUTO. Área: Gestión Gestión de Procesos de Negocios BPM Parte III: BPM Aspectos Técnicos

Más detalles

SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES

SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES 2003 Factores externos que afectan a la empresa industrial El nuevo contexto económico global impone a las empresas industriales mejoras de calidad,

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características

Más detalles

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

Más detalles

Management(BPM) Gestión de Proceso de negocio con BPM. Universidad Inca Garcilaso de la Vega

Management(BPM) Gestión de Proceso de negocio con BPM. Universidad Inca Garcilaso de la Vega Universidad Inca Garcilaso de la Vega CURSO DE ACTUALIZACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS Y CÓMPUTO Business Process Business Process Management(BPM) Management(BPM) MSc. Daniel Alejandro Yucra

Más detalles

MODELACION Y ANALISIS DE PROCESOS EMPRESARIALES MAPE

MODELACION Y ANALISIS DE PROCESOS EMPRESARIALES MAPE MODELACION Y ANALISIS DE PROCESOS EMPRESARIALES MAPE Thomas A. Little Ph. D Traducción Autorizada por el Autor. Traductor: MANUEL H RAMIREZ Alta Via Consulting-América Latina La Modelación y Análisis de

Más detalles

El valor de una infraestructura optimizada

El valor de una infraestructura optimizada El valor de una infraestructura optimizada El Estudio del Estado del CIO 2006 (CIO Research, 2006) muestra que los CIO están buscando, cada vez más, introducir, de forma proactiva, soluciones de tecnología

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Introducción a BPM. Programa BPM Business Process Management. Al finalizar el capítulo, el alumno podrá:

Introducción a BPM. Programa BPM Business Process Management. Al finalizar el capítulo, el alumno podrá: Introducción a BPM Al finalizar el capítulo, el alumno podrá: Comprender la importancia de la Gestión de Procesos y la mejora continua de los mismos. Identificar los diferentes procesos existentes en una

Más detalles

Cristian Blanco www.cristianblanco.es

Cristian Blanco www.cristianblanco.es 3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Aproximación al CONCEPTO

Aproximación al CONCEPTO 18 Aproximación al CONCEPTO LA NECESIDAD DE INTERCAMBIAR INFORMACIÓN ENTRE DEPARTAMENTOS Y ÁREAS DE NEGOCIO SE HA VUELTO CRUCIAL Y HA HECHO QUE LAS EMPRESAS VEAN LA INTEGRACIÓN COMO UN ELEMENTO CLAVE PARA

Más detalles

DISEÑO DE UN SISTEMA INFORMÁTICO PARA LA

DISEÑO DE UN SISTEMA INFORMÁTICO PARA LA DISEÑO DE UN SISTEMA INFORMÁTICO PARA LA ADMINISTRACIÓN DE COMPRAS DE ALMACÉN INITE, S.C. no es responsable del contenido, de la veracidad de los datos, opiniones y acontecimientos vertidos en el presente

Más detalles

Etapas del desarrollo

Etapas del desarrollo Capítulo 4 Etapas del desarrollo Este capítulo documenta la aplicación del modelo presentado anteriormente, para el caso de la detección y clasificación de eventos sísmicos sobre señales digitales. El

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

REQUISITOS PARA LA SOLICITUD DE EVALUACIÓN DE RECURSOS DIGITALES CON FINES DE APRENDIZAJE Y PROMOCIÓN DE LA ORIGINALIDAD DEL MATERIAL EDUCATIVO

REQUISITOS PARA LA SOLICITUD DE EVALUACIÓN DE RECURSOS DIGITALES CON FINES DE APRENDIZAJE Y PROMOCIÓN DE LA ORIGINALIDAD DEL MATERIAL EDUCATIVO REQUISITOS PARA LA SOLICITUD DE EVALUACIÓN DE RECURSOS DIGITALES CON FINES DE APRENDIZAJE Y PROMOCIÓN DE LA ORIGINALIDAD DEL MATERIAL EDUCATIVO El Sistema de Universidad Virtual (SUV) se ha enfocado en

Más detalles

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio BPM Business Process Management Gestión de Procesos de Negocio Palabras Clave: BPM, Business Process Management, Workflow, Gestión de Procesos de Negocio, Reingeniería de Procesos, Optimización de Procesos,

Más detalles

INTEGRACIÓN DE SISTEMAS HEREDADOS

INTEGRACIÓN DE SISTEMAS HEREDADOS CAPÍTULO 2 INTEGRACIÓN DE SISTEMAS HEREDADOS En el presente capítulo, se presenta el problema de integración de sistemas de Software. Una de cuyas características es la presencia de los llamados Sistemas

Más detalles

Metodologías para generación de Sistemas Orientados a Objetos

Metodologías para generación de Sistemas Orientados a Objetos Metodologías para generación de Sistemas Orientados a Objetos Análisis y Diseño (Tecnologías) Orientado a Objetos Dr. Leopoldo Altamirano Robles 22 septiembre, 2003 Alicia Morales Reyes Alma Rosa Rugerio

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

LOS INDICADORES DE GESTIÓN

LOS INDICADORES DE GESTIÓN LOS INDICADORES DE GESTIÓN Autor: Carlos Mario Pérez Jaramillo Todas las actividades pueden medirse con parámetros que enfocados a la toma de decisiones son señales para monitorear la gestión, así se asegura

Más detalles

BPM - Gestión de Procesos

BPM - Gestión de Procesos BPM - Gestión de Procesos Proyecto SIIF 2 con enfoque en procesos Ing. Pablo Morales pmorales@bpfocus.org "Las organizaciones a menudo fallan al no comprender que su efectividad puede mejorar drásticamente

Más detalles

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Mario R. MORENO SABIDO Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México y Jorge

Más detalles

Centro de Investigación y Desarrollo en Ingeniería en Sistemas de Información (CIDISI)

Centro de Investigación y Desarrollo en Ingeniería en Sistemas de Información (CIDISI) Centro de Investigación y Desarrollo en Ingeniería en Sistemas de Información (CIDISI) OFERTAS TECNOLÓGICAS 1) GESTIÓN ORGANIZACIONAL Y LOGÍSTICA INTEGRADA: TÉCNICAS Y SISTEMAS DE INFORMACIÓN 2) GESTIÓN

Más detalles

Procesos de Negocios. Ingeniería de Sistemas de Información /Sistemas de Información ISI/SI - 1

Procesos de Negocios. Ingeniería de Sistemas de Información /Sistemas de Información ISI/SI - 1 Procesos de Negocios Ingeniería de Sistemas de Información /Sistemas de Información ISI/SI - 1 Procesos de negocios Como dijimos en el Tema 2: los sistemas de información y las organizaciones se influyen

Más detalles

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el

Más detalles

Plataforma Tecnológica Qué es Marino Imagine? La integración de los requerimientos de sistemas informáticos en la determinados sectores. infraestructura de la empresa ha sucedido de forma Sus carencias

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

RESUMEN de la GESTIÓN de PROYECTOS

RESUMEN de la GESTIÓN de PROYECTOS RESUMEN de la GESTIÓN de PROYECTOS Basado en la Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK ) Contenidos Introducción...2 PMI...2 Objetivos...2 PMBOK...2 Proyecto...3 Concepto...3

Más detalles

SOFTWARE COLABORATIVO

SOFTWARE COLABORATIVO SOFTWARE COLABORATIVO Software colaborativo o groupware son un conjunto de programas informáticos que integran el trabajo en un sólo proyecto con muchos usuarios concurrentes que se encuentran en diversas

Más detalles

Monitoreo automatizado de redes de. cajeros automáticos

Monitoreo automatizado de redes de. cajeros automáticos Monitoreo automatizado de redes de cajeros automáticos Definición Ejecutiva ATMonitor es una solución completa, integrada y flexible de monitoreo visual de una red de cajeros automáticos. Centraliza la

Más detalles

AUDITORIA DE SISTEMAS. Jorge Alberto Blanco Duarte

AUDITORIA DE SISTEMAS. Jorge Alberto Blanco Duarte AUDITORIA DE SISTEMAS Jorge Alberto Blanco Duarte QUE ES LA AUDITORIA DE SISTEMAS? La auditoria en informática es la revisión y la evaluación de los controles, sistemas, procedimientos de informática;

Más detalles

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA)

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA) Espiñeira, Sheldon y Asociados * No. 12-2009 *connectedthinking Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción

Más detalles

ACP07. Que es un erp.

ACP07. Que es un erp. UNIVERSIDAD AUTONOMA DE GUADALAJARA ACP07. Que es un erp. JOSE DE JESUS CISNEROS PEREZ REG. 1996632 TECNOLOGIAS DE LA INFORMACION Los sistemas de planificación de recursos empresariales (en inglés ERP,

Más detalles