1

COMPARATIVO ENTRE EL MODELO TRADICIONAL DE DESARROLLO DE

SOFTWARE Y LA IMPLEMENTACIÓN DE BPM Y ARQUITECTURA SOA EN LA FASE DE ANALISIS, PARA EL SUBPROCESO DE GESTION DE HOJAS DE VIDA EN LA

EMPRESA EXTRAS Y EFICACIA

EUNICE BORJA MARIA EMMA FLOREZ

PAOLA A. TORRES LEON

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

ESPECIALIZACIÓN EN PROCESOS PARA EL DESARROLLO DE SOFTWARE SANTIAGO DE CALI

2011

2

COMPARATIVO ENTRE EL MODELO TRADICIONAL DE DESARROLLO DE SOFTWARE Y LA IMPLEMENTACIÓN DE BPM Y ARQUITECTURA SOA EN LA FASE

DE ANALISIS, PARA EL SUBPROCESO DE GESTION DE HOJAS DE VIDA EN LA EMPRESA EXTRAS Y EFICACIA

Presentado por:

EUNICE BORJA MARIA EMMA FLOREZ

PAOLA A. TORRES LEON

Trabajo de Grado presentado como requisito para optar el título de Especialista en Procesos para el Desarrollo de Software

Director: Phd LUIS MERCHÁN PAREDES

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

ESPECIALIZACIÓN EN PROCESOS PARA EL DESARROLLO DE SOFTWARE SANTIAGO DE CALI

3

2011

TABLA DE CONTENIDO TABLA DE CONTENIDO .................................................................................................. 3 INTRODUCCION .............................................................................................................. 7 1. GENERALIDADES ..................................................................................................... 8 1.1 PLANTEAMIENTO DEL PROBLEMA ..................................................................... 8 1.2 OBJETIVOS ............................................................................................................ 9

1.2.1 Objetivo General .............................................................................................. 9 1.2.2 Objetivos Específicos ....................................................................................... 9

1.3 JUSTIFICACION ..................................................................................................... 9 1.4 IMPACTOS ESPERADOS DEL PROYECTO ....................................................... 10 1.5 PLAN DE TRABAJO ............................................................................................. 11

1.5.1 Fase: Planeación............................................................................................ 11 1.5.2 Fase: Análisis y Diseño: ................................................................................. 11 1.5.3 Fase: Ejecución: ............................................................................................. 11

2 MARCO TEORICO .................................................................................................. 12 2.1 Teoría de Procesos .............................................................................................. 12

2.1.1 Introducción a los procesos ............................................................................ 12 2.1.2 Definición de los procesos ............................................................................. 12 2.1.3 Características de los Procesos ..................................................................... 14 2.1.4 Componentes de los procesos ....................................................................... 14 2.1.5 Tipos de procesos .......................................................................................... 15 2.1.6 Gestión por procesos ..................................................................................... 16 2.1.6.1 Introducción a la gestión por procesos ....................................................... 16 2.1.6.2 Definición de gestión por procesos ............................................................. 16 2.1.6.3 Diferencias entre gestión por funciones y gestión por procesos ................. 16 2.1.6.4 Pasos para gestión por procesos ................................................................ 17 2.1.6.4.1 Levantamiento de procesos ..................................................................... 17 2.1.6.4.2 Mapeo de Procesos ................................................................................. 18 2.1.6.4.3 Simbología utilizada para representar procesos ...................................... 18 2.1.7 Modelado de procesos ................................................................................... 19 2.1.8 Workflow ........................................................................................................ 19 2.1.9 BPM (Business Process Management) .......................................................... 20 2.1.9.1 Introducción a BPM ..................................................................................... 20 2.1.10 Historia del BPM ......................................................................................... 22 2.1.10.1 Importancia del BPM ............................................................................... 22 2.1.10.2 Disciplinas de BPM .................................................................................. 25

2.2 Arquitectura Orientada a Servicios SOA: .............................................................. 27 2.2.1 Terminología SOA ......................................................................................... 28

2.3 Diseño y Desarrollo SOA ...................................................................................... 29 2.3.1 Contrato de Servicio ....................................................................................... 29 2.3.2 Servicios Web ................................................................................................ 30

2.4 Bus de integración de servicios corporativos (Enterprise Service Bus) ................ 31

4

3 Detalle de la fase de análisis tradicional y análisis con BPM ................................... 33 3.1 Metodología Análisis Tradicional .......................................................................... 33

3.1.1 Definición Cronograma método tradicional .................................................... 34 3.1.2 Análisis subproceso de gestión de hojas de vida ........................................... 34 3.1.2.1 Diagramas de Casos de uso (Situación Actual) .......................................... 34 3.1.2.1.1 Fuentes de Reclutamiento Hojas de Vida ................................................ 34 3.1.2.1.2 Gestión Hojas de Vida ............................................................................. 35 3.1.2.1.3 Cargues masivos Hojas de Vida .............................................................. 35 3.1.2.2 Modelo Conceptual del Sistema ................................................................. 36

3.2 Análisis Proceso Actual con BPM ......................................................................... 36 3.2.1 Análisis con BPM ........................................................................................... 36 3.2.2 Definición Cronograma Análisis con BPM ...................................................... 37 3.2.3 Análisis modelo BPM ..................................................................................... 37 3.2.3.1 Descubrimiento del subproceso de gestión de hojas de vida: .................... 37 3.2.3.2 Modelamiento del flujo actual del subproceso de gestión de hojas : .......... 38 3.2.3.2.1 Workflow subproceso actual .................................................................... 38 3.2.3.2.2 Diagrama actual de áreas del subproceso y actividades de hoja de vida 39 3.2.3.3 Definición de las reglas de negocio para la gestión de hojas de vida: ........ 40 3.2.3.4 Mejoramiento del flujo del subproceso: ....................................................... 40 3.2.3.4.1 Workflow proceso propuesto ................................................................... 40 3.2.3.4.2 Diagrama de áreas de proceso y actividades .......................................... 41

4 Análisis comparativo de modelos tradicional y BPM ................................................ 42 4.1 Tiempos invertidos por fase .................................................................................. 42 4.2 Tiempos invertidos por rol ..................................................................................... 43 4.3 Esfuerzo en días ................................................................................................... 44 4.4 Número de personas ............................................................................................ 44 4.5 Costos del recurso ................................................................................................ 45 4.6 Tareas Críticas ..................................................................................................... 45 4.7 Comparativo entre los modelos de estudio en la fase de Análisis ........................ 46 5 Diseño Sistema Integrador de Interfaces ................................................................. 48 5.1 Diseño de Arquitectura para la integración de servicios SOA ............................... 48 5.2 Características de los servicios ............................................................................ 49 6 TRABAJO FUTUROS .............................................................................................. 50 7 CONCLUSIONES .................................................................................................... 51 8 GLOSARIO .............................................................................................................. 53 BIBLIOGRAFIA ............................................................................................................... 57

5

LISTA DE FIGURAS

Figura 1- Gráfica de Procesos ................................................................................. 13 Figura 2- Proceso .................................................................................................... 14 Figura 3- Gráfica de Macro y Micro Procesos ......................................................... 15 Figura 4- Gráfica Workflow (Capas Arquitectura Empresarial) ................................ 20 Figura 5 - BPM ........................................................................................................ 23 Figura 6 - Integración BPM ...................................................................................... 24 Figura 7 - Disciplinas ............................................................................................... 25 Figura 8 – Ciclo de vida BPM .................................................................................. 27 Figura 9 – Contrato de Servicios ............................................................................. 30 Figura 10 – Tecnologías Orientadas a Servicios ..................................................... 31 Figura 11 – Arquitectura ESB .................................................................................. 32 Figura 12 – Cronograma Análisis con Método Tradicional ...................................... 34 Figura 13 – Caso de Uso Fuentes de Reclutamiento .............................................. 34 Figura 14 - Caso de Uso Gestión de Hojas de Vida ................................................ 35 Figura 15 - Caso de Uso Cargues masivos de Hoja de Vida .................................. 35 Figura 16 – Modelo Conceptual............................................................................... 36 Figura 17 – Mapa de procesos empresa Extras y Eficacia ...................................... 36 Figura 18 – Cronograma Análisis con BPM ............................................................. 37 Figura 19 – Diagrama de flujo proceso de preselección de talento ......................... 38 Figura 20 – WorkFlow subproceso actual .............................................................. 39 Figura 21 - Diagrama de Áreas del subproceso y sus Actividades ......................... 39 Figura 22 – WorkFlow Proceso Propuesto .............................................................. 41 Figura 23 – Diagrama de Áreas de Procesos y sus Actividades ............................. 41 Figura 24 – Diagrama comparativo de tiempos invertidos por fase ......................... 42 Figura 25 – Diagrama comparativo de tiempos invertidos por rol ........................... 43 Figura 26 – Diagrama comparativo de esfuerzo en días ......................................... 44 Figura 27 – Diagrama comparativo de Recursos en # de Personas ....................... 44 Figura 28 –Diagrama comparativo de Costos ......................................................... 45 Figura 29 – Diagrama de Tareas Críticas con Modelo ............................................ 46 Figura 30 – Diagrama de Tareas Críticas con BPM ................................................ 46 Figura 31 – Diseño de Arquitectura SOA para la integración de servicios SOA ...... 48

6

LISTA DE TABLAS

Tabla 1- Diferencias entre gestión por funciones y gestión por procesos ............... 17 Tabla 2- Simbología para representar procesos ..................................................... 19 Tabla 3 – Terminología SOA ................................................................................... 29 Tabla 4 – Comparativo entre los modelos de estudio en la fase de análisis ........... 47

7

INTRODUCCION

En los últimos años las empresas han visto como a nivel mundial ha proliferado la competencia. La mentalidad competitiva es hoy un requisito indispensable para que toda organización alcance los siguientes objetivos: supervivencia, crecimiento y utilidad. Actualmente la calidad y productividad son factores muy importantes para la competitividad de las empresas en un mundo de globalización. Las empresas tienen la necesidad de ser cada día más competitivas y tratan de lograr la mejora continua de sus productos y procesos a través de la generación de procesos de aprendizaje y la acumulación de conocimientos tecnológicos. La tecnología como agente de cambio, se ha convertido en un factor decisivo en el éxito del desempeño de las organizaciones y es una de las ventajas competitivas más efectivas, por ello la empresa Extras y Eficacia no es ajena a esta visión y surge entonces la necesidad de determinar estrategias que permitan establecer integraciones con socios de negocio para intercambiar información que se convertirá en materia prima para los procesos de reclutamiento, selección y vinculación de personal y poder responder a la demanda de solicitudes de personal que hacen sus clientes en la diferentes líneas de negocio con agilidad, efectividad y oportunidad. El presente proyecto tiene como finalidad mostrar un comparativo de la aplicación de los modelos tradicional (ciclo de vida) y modelo BPM (Business Process Management) con implementación de arquitectura SOA (Service Oriented Architecture), en la fase análisis de desarrollo de software, tomando como caso de estudio el desarrollo del subproceso de gestión de hojas de vida y su integración al sistema ADAM de la empresa Extras y Eficacia con su socio de negocio el portal de empleo Buscojobs.

8

CAPITULO 1.

1. GENERALIDADES

1.1 PLANTEAMIENTO DEL PROBLEMA

Factores como la calidad y productividad permiten medir la competitividad de las empresas en un mundo de globalización lo cual conlleva a que las empresas estén en constante mejora continua en sus procesos y productos, a raíz de esta necesidad decidimos investigar y determinar la problemática que presenta el subproceso de gestión de hojas de vida de la empresa Extras y Eficacia. Existen métodos manuales de digitación para ingresar la información de las hojas de vida al sistema ADAM en el módulo de selección de personal, lo cual aumenta los errores en el ingreso de datos al sistema. Las hojas de vida se vuelven obsoletas, no existen medios para que los candidatos actualicen la información personal (dirección, teléfonos, correos electrónicos), nuevas experiencias laborales, estudios y conocimientos. Las fotos de las hojas de vida quedan en el archivo físico, no son escaneadas cuando el candidato hace entrega de su curriculum en las oficinas de la empresa Extras y Eficacia. Se pierde la trazabilidad de los análisis de cada candidato, todo queda en papel, escrito a mano o en los equipos de cada analista de selección. La publicación de ofertas de empleo para búsqueda de personal se hace a través de portales de empleo que no tienen ninguna integración automática con el sistema de recursos humanos de la empresa llamado ADAM, lo cual implica perdida de información de las hojas de vida analizadas y que no son registrados en los sistemas. El registro de la citación del personal (tanto para pruebas, entrevistas y contratación) se hace por fuera del sistema, por medio de correos electrónicos o de listados en físico porque la hoja de vida no se graba en el sistema hasta que la persona no es seleccionada. Finalmente no se tiene una trazabilidad del proceso desde la consulta de candidatos hasta la contratación.

9

1.2 OBJETIVOS

1.2.1 Objet ivo General

Realizar un comparativo entre el desarrollo de la fase de análisis elaborado bajo el modelo tradicional (ciclo de vida) vs modelo BPM (Business Process Management) con implementación de arquitectura SOA, tomando como caso de estudio el desarrollo del subproceso de gestión de hojas de vida y su integración al sistema ADAM de la empresa Extras y Eficacia con su socio de negocio el portal de empleo Buscojobs.

1 .2 .2 Objet ivos Específ icos

Modelar el subproceso de gestión de hojas de vida aplicando tecnología BPM

Optimizar el subproceso de gestión de hojas de vida aplicando tecnología BPM. Generar una comparación de tiempo, costo y recursos con el modelo actual y el

optimizado en el subproceso de gestión de hojas de vida.

Generar una comparación del ciclo de desarrollo de software en la fase de análisis tradicional vs análisis con BPM determinando las ventajas y/o desventajas destacadas en el sub proceso de gestión de hojas de vida.

Mostrar una propuesta de análisis con BPM y diseño con la arquitectura SOA requerida para integrar los sistemas de hojas de vida entre la empresa Extras y Eficacia y su socio de negocio BuscoJobs.

1.3 JUSTIFICACION Uno de los principales retos que se plantean a los responsables de TI (tecnologías de información) o directivos es la capacidad de identificar y conocer los procesos del negocio, y ser capaces de dominarlos. Es muy habitual observar como una empresa y sus áreas de negocio no tienen bien identificados y monitorizados sus procesos, que son el elemento fundamental de toda organización. Por esta razón, la implementación de BPM es de gran importancia, permitirá administrar de manera unificada las personas, los procesos y la información de una organización, y establece ventajas como la incorporación de contenidos dentro de los procesos para agilizar el trabajo de los usuarios, la posibilidad de integrar tanto a empleados, clientes, proveedores y colaboradores dentro de ellos, logrando una mayor trazabilidad y un menor número de errores en la información que manipulan. En síntesis la “ELABORACIÓN DE UN COMPARATIVO ENTRE EL METODO TRADICIONAL EN LA FASE DE ANALISIS VS. ANALISIS BAJO BPM”, es una revisión

10

de los modelos tradicional y BPM con implementación de arquitectura SOA y que permitirá determinar las ventajas y desventajas de ambos modelos, así como mejoras en el caso de estudio del subproceso de gestión de hojas de vida. Una vez modelado el proceso actual de hojas de vida se presentará la simulación del proceso propuesto con BPM y la arquitectura orientada a servicios web SOA la cual permitirá integrar los sistemas para:

Crear hojas de vida en línea.

Actualizar hojas de vida en línea.

Consultar hojas de vida en línea.

Obtener trazabilidad de las hojas de vida.

Mantener un banco de hojas de vida actualizado y disponible.

Minimizar el sobre esfuerzo de las actividades involucradas en el subproceso de gestión de las hojas de vida que no están quedando grabadas en el sistema.

Monitorear y controlar las actividades del subproceso de preselección.

Tener un referente para poder implementar la tecnología de BPM en futuros procesos de desarrollo de software.

1.4 IMPACTOS ESPERADOS DEL PROYECTO

Presentar una propuesta de integración que permita tener un sistema actualizado con los datos de la hoja de vida de los candidatos para los subprocesos de reclutamiento, selección y vinculación.

Mostrar como los subprocesos realizados a los candidatos pueden tener un flujo controlado, gestionado las actividades de valoración para cumplimiento de las reglas de negocio que se aplican, permitiendo trabajo colaborativo entre las diferentes áreas del subproceso de selección y vinculación de talentos, disminuyendo la duplicidad de tareas y dejando la trazabilidad de las actividades realizadas.

Utilizar la tecnología BPM para la modelar el subproceso de gestión de hojas de vida y que sea un marco de referencia para la mejora de otros subprocesos y procesos de la empresa Extras y Eficacia.

Proponer una arquitectura de Integración para interconexión con sistemas externos de proveedores y socios de negocio de la empresa Extras y Eficacia.

11

1.5 PLAN DE TRABAJO

1.5.1 Fase: Planeación

1. Definición del cronograma de trabajo

2. Planteamiento del problema

3. Investigación marco teórico

Investigación Teoría de Procesos

Investigación BPM

Investigación Arquitectura SOA

4. Levantamiento de información del proceso

Flujo del proceso

Problemas

1.5.2 Fase: Análisis y Diseño:

5. Análisis del subproceso actual de gestión de hojas de vida

6. Optimización del subproceso de gestión de hojas de vida con BPM

7. Propuesta de análisis y diseño con implementación de arquitectura orientada a servicios SOA.

1.5.3 Fase: Ejecución:

8. Comparación con el modelo actual y optimizado en tiempo, costo y recurso en

el subproceso de gestión de hojas de vida.

9. Comparación del ciclo de desarrollo de software en la fase de análisis tradicional vs análisis con BPM.

10. Diseño de la arquitectura de integración entre la empresa Extras y Eficacia y el su socio de negocio Buscojobs.

12

CAPITULO 2.

2 MARCO TEORICO

2.1 Teor ía de Procesos

2.1.1 Int roducción a los procesos

Los procesos han existido desde siempre en la actividad humana en la medida que seguimos de forma sistemática un proceso, ya sea conscientemente o no, para las distintas operaciones. Todo proceso tiene entradas, recursos humanos, tecnológicos, materiales y otros para el desarrollo de las actividades que lo conforman; como salidas se esperan productos, servicios, información, activos financieros u otros. Si bien la distinción entre actividad y proceso no es nítida, por lo general un proceso es visto como un conjunto de actividades o una macro actividad. Los subprocesos son partes bien definidas en un proceso. Su identificación puede resultar útil para aislar los problemas que pueden presentarse y posibilitar diferentes tratamientos dentro del mismo. Los procedimientos representan la forma específica de llevar a cabo una actividad; qué debe hacerse y quien debe hacerlo; cuando, donde y como se debe llevar a cabo; qué materiales, equipos y documentos deben utilizarse; y como deben controlarse y registrarse. Las actividades son la suma de tareas y normalmente se agrupan en un procedimiento para facilitar su gestión. La secuencia ordenada de actividades da como resultado un subproceso o un proceso.

2.1.2 Def inición de los procesos

La palabra proceso viene del latín PROCESSUS, que significa avance y progreso. Un proceso es el conjunto de actividades de trabajo interrelacionadas que se caracterizan por requerir ciertos insumos (productos o servicios de otros proveedores) y tareas particulares que implican valor añadido con miras a obtener ciertos resultados (ver figura 1). Proceso no es lo mismo que procedimiento. Un procedimiento es el conjunto de reglas e instrucciones que determinan la manera de proceder o de obrar para conseguir un

13

resultado. Un proceso define que es lo que se hace, y un procedimiento el cómo hacerlo. Todo proceso forma parte de un conjunto de elementos que interactúan para lograr un propósito común, a esto se le conoce como SISTEMA.

Figura 1- Gráfica de Procesos

Otra posible definición: A principios de los años noventa, Michael Hammer define el concepto de Proceso de Negocio como un “conjunto de actividades que reciben uno o más insumos y crea un producto de valor para el cliente”. Otra definición, entiende todo proceso como un "conjunto de tareas lógicamente relacionadas que existen para obtener un resultado bien definido dentro de un negocio". Según Smith y Fingar 2003 “Un proceso de negocio es el conjunto completo y coordinado de actividades colaborativas y transaccionales que proporcionan valor a los clientes”. Según la norma ISO 9000:2000 un proceso es “un conjunto de actividades mutuamente relacionadas o que interactúan, las cuales transforman elementos de entrada en resultados”. A partir de lo anterior, se puede deducir que el enfoque basado en procesos enfatiza cómo los resultados que se desean obtener se pueden alcanzar de manera más eficiente si se consideran las actividades agrupadas entre sí, considerando a su vez, que dichas actividades deben permitir una transformación de unas entradas en salidas y que en dicha transformación se debe aportar valor, al tiempo que se ejerce un control sobre el conjunto de actividades (ver figura 2). No todas las actividades que se realizan son procesos. Para determinar si una actividad realizada por una organización es un proceso o subproceso, debe cumplir los siguientes criterios:

La actividad tiene una misión o propósito claro. La actividad contiene entradas y salidas, se pueden identificar los clientes, proveedores y producto final.

La actividad debe ser susceptible de descomponerse en operaciones o tareas.

14

La actividad puede ser estabilizada mediante la aplicación de la metodología de gestión por procesos (tiempo, recursos, costes). Se puede asignar la responsabilidad del proceso a una persona.

Figura 2- Proceso

2.1.3 Caract er íst icas de los Procesos

Es definido por un verbo de acción en infinitivo que denota la cualidad de imperativo (terminaciones ar, er, ir). Ejemplo: Nómina no es un proceso, elaborar la nómina sí.

Tiene un principio y un fin (límites).

La finalidad de un proceso es generar un producto o servicio.

Existen para satisfacer la necesidad de un cliente.

Todo proceso tiene un dueño.

Transforma o complementan las entradas (valor agregado).

Se representan en un diagrama.

Debe ser evaluado.

Debe ser mejorado.

2.1.4 Com ponent es de los procesos

Recursos humanos: Es el conjunto de personas con conocimientos, habilidades y aptitudes que forman parte de una organización para resolver una necesidad o llevar a cabo una actividad dentro de esta. Medio ambiente: Conjunto de condiciones bajo las cuales se realiza el trabajo. Insumos: Son los bienes y servicios que se incorporan al proceso, que con el trabajo de los empleados y el apoyo de equipo, son transformados en otros bienes y /o servicios con un valor agregado mayor. Equipo: Instrumentos y aparatos que utiliza el capital humano para agilizar uno o varios procesos y así transformar los insumos en productos y /o servicios. Método: Procedimiento o modo de decir o hacer con orden una cosa.

15

2.1.5 Tipos de procesos

Según el cliente al cual vayan dirigidos se dividen en: Clave: Son los procesos que tienen contacto directo con el cliente, (los procesos operativos necesarios para la realización del producto/servicio, a partir de los cuales el cliente percibirá y valorará la calidad: comercialización, planificación del servicio, prestación del servicio, entrega, facturación). Estratégicos: Son los procesos responsables de analizar las necesidades y condicionantes de la sociedad, del mercado y de los accionistas, para asegurar la respuesta a las mencionadas necesidades y condicionantes estratégicos (procesos de gestión responsabilidad de la Dirección: marketing, recursos humanos, gestión de la calidad). Soporte: Son aquellos que permiten la operación de la institución procesos administrativos, pagar nómina, contabilidad, compras. Por las áreas involucradas se dividen en (ver figura 3):

Macro procesos: Proceso global, de gran alcance que normalmente suele atravesar las delimitaciones de una unidad o área de trabajo.

Micro procesos: Un proceso más definido compuesto de una serie de pasos y actividades detalladas. Podría ser llevado a cabo por una sola persona. Un microproceso puede convertirse en un subproceso de un macro proceso.

Figura 3- Gráfica de Macro y Micro Procesos

Los procesos pueden también ser clasificados en:

Procesos multidepartamentales: Sus actividades se realizan integrando varios departamentos, servicios o unidades. Lógicamente son los más complejos.

Procesos departamentales o unifuncionales. Aquel llevado a cabo por un solo departamento.

16

2.1.6 Gest ión por procesos

2.1.6 .1 Int roducción a la gest ión por pr ocesos

La gestión por procesos apoya para que una empresa sea más eficiente, permitiéndole ser más dinámica y preparada para los cambios. Transforma a la empresa para que todos los empleados compartan una misma visión con comunicación fluida y abierta. Los servicios de gestión incluyen:

Análisis y levantamiento de procesos

Optimización y mejora de los procesos

Transformación cultural de la empresa para que gestione por procesos.

¿Para qué la Gestión por Procesos?

Mejora continua de las actividades desarrolladas

Reducir la variabilidad innecesaria

Eliminar las ineficiencias asociadas a la repetitividad de las actividades

Optimizar el empleo de los recursos

2.1.6 .2 Def inición de gest ión por pr ocesos

Conjunto de actuaciones, decisiones, actividades y tareas que se encadenan de forma secuencial y ordenada para conseguir un resultado que satisfaga plenamente los requerimientos al cliente que va dirigido.

La gestión por procesos aporta una visión y unas herramientas con las que se puede mejorar y rediseñar el flujo de trabajo para hacerlo más eficiente y adaptado a las necesidades del cliente. No hay que olvidar que los procesos lo realizan personas y los productos los reciben personas, y por tanto hay que tener en cuenta en todo momento las relaciones entre proveedores y clientes.

2.1.6 .3 Dif erencias ent re gest ión por f unciones y gest ión por

procesos

La tabla 1 presenta las diferencias entre la gestión por funciones y la gestión por procesos.

17

Gestión funcional Gestión de Procesos

Organización de departamentos o áreas Organización orientada a procesos

Los departamentos condicionan la ejecución de las actividades

Los procesos de valor añadido condicional la ejecución de las actividades

Autoridad basada en jefes departamentales

Autoridad basada en los responsables del proceso

Principio de Jerarquía y de control Principio de autonomía y autocontrol

Orientación interna de las actividades hacia el jefe o departamento

Orientación externa hacia el cliente interno o externo

Principios de burocracia , formalismo y centralización en la toma de decisiones

Principios de eficiencia, flexibilidad y descentralización en la toma de decisiones.

Ejercido del mando por control basado en la vigilancia

Ejercicio del mando por excepción basado en el apoyo o la supervisión

Principio de eficiencia: ser mas proactivo

Principio de eficacia: ser más competitivos

Como hacer mejor lo que venimos haciendo

Para quien lo hacemos y que debemos hacer.

Las mejoras tienen un ámbito limitado: el departamento

Las mejoras tienen un ámbito transfuncional y generalizado : el proceso

Tabla 1- Diferencias entre gestión por funciones y gestión por procesos

2.1.6 .4 Pasos para gest ión por procesos

Identificar clientes y sus necesidades

Definir servicios/productos

Desarrollar el mapa de procesos

Describir procesos

Diagramar procesos

Análisis de datos y mejora del proceso

2.1.6.4.1 Levant am ient o de procesos

Para el levantamiento y análisis de los procesos se usa una serie de herramientas que permiten diagnosticar y proponer mejoras que beneficien el desempeño de la Organización. El diagrama del proceso, es una representación gráfica de la secuencia en que se realizan las actividades necesarias para desarrollar un proceso permitiendo a su vez:

18

Identificar quien realiza el proceso: ¿Quién es el responsable del proceso?, ¿Quién interviene en el proceso?

Realizar una lista de las actividades que intervienen en el proceso: ¿Cuántas actividades realizo en el proceso?, ¿Cuánta gente interviene? ¿Qué revisiones/verificaciones se realizan?

Reconocer el principio y el fin del proceso

Ordenar las actividades

Para el levantamiento del proceso se utiliza entre otras las siguientes herramientas

Diagramas de Flujo

Diagramas de Actividades

2.1.6 .4 .2 Mapeo de Procesos

Es la representación gráfica de un conjunto de actividades relacionadas, bajo una simbología establecida y consiste en la identificación de procesos relacionados con la Administración del negocio y de la Fabricación del Producto/Servicio. Pasos para el Mapeo de Procesos

Definir el mapa de proceso

Identificar la actividad que da inicio al proceso

Identificar la relación entre los procesos

Crear una secuencia entre ellos

Identificar el soporte documental de cada proceso descrito.

Importancia del diagrama:

Ejemplifica gráficamente el proceso actual.

Permite conocer el tiempo en que se realiza cada actividad.

Muestra los responsables y su actividad dentro del proceso.

Es un instrumento que facilita la elaboración de procedimientos escritos y sus requerimientos.

Facilita la identificación de actividades innecesarias y situaciones problemáticas (repetición de tareas, tiempos muertos, cuellos de botella, etc.).

Ayuda a documentar y estandarizar el proceso.

Es un instrumento de capacitación.

2.1.6 .4 .3 Sim bología ut ilizada para represent ar procesos

Los símbolos más utilizados para representar los flujos de los procesos se representan en la tabla 2:

19

Símbolo Representa Descripción

Límites Este símbolo se usa para identificar el inicio y el fin de un proceso

Operación Representa una etapa del proceso. El nombre de la etapa y de quien la ejecuta se registran al interior del rectángulo

Documento Simboliza al documento resultante de la operación respectiva. En su interior se anota el nombre que corresponda

Decisión Representa al punto del proceso donde se debe tomar una decisión. La pregunta se escribe dentro del rombo. Dos flechas que salen del rombo muestran la dirección del proceso, en función de la respuesta real

Sentido del flujo

Significa el sentido y la secuencia de las etapas del proceso

Tabla 2- Simbología para representar procesos

2.1.7 Modelado de procesos

El modelado de procesos de negocio será una red de objetos gráficos, correspondientes a actividades y controles de flujo que definen el orden de ejecución de éstas. BPMN, UML son lenguajes que permiten modelar procesos de negocio. Sin embargo cada uno de ellos considera ciertos aspectos de la realidad. BPMN Una notación estándar para el modelamiento de los procesos de negocio, la cual permite entender los procesos internos a través de una notación gráfica. Establece una relación entre los elementos gráficos y los constructores de los bloques estructurados del lenguaje de ejecución de procesos (BPEL). BPML Es el lenguaje en el que se modelan los procesos de negocio, se puede definir como un metalenguaje para modelar los procesos. BPML proporciona un modelo abstracto de la ejecución para los procesos de colaboración y transaccionales del negocio basados en el concepto de una máquina transaccional de estado.

2.1.8 Workf low

Workflow es la automatización de los procesos de negocio durante el cual documentos, información y tareas son pasados de un participante a otro.

20

Un sistema para la gestión del trabajo provee beneficios tanto a trabajadores como a la organización. Las tareas de los trabajadores se realizan más fácilmente y la organización conoce y controla las tareas que se llevan a cabo. Para entenderlo mejor, a través de la figura 5 podemos ver que existen diferentes capas en la arquitectura empresarial: Bases de datos, sistemas y aplicaciones, procesos de negocio y roles (clientes, personal, proveedores, partners, etc.). El objetivo de un sistema de workflow es a través de un motor, gestionar de forma automatizada los procesos y flujo de actividades, documentos, imágenes y datos, orquestando e integrando los recursos informáticos y los roles.

Figura 4- Gráfica Workflow (Capas Arquitectura Empresarial)

Con la Tecnología WorkFlow:

El trabajo no queda atascado o extraviado.

Los jefes pueden enfocarse más en los problemas del negocio y del personal, tal como el rendimiento, capacitación individual, mejoras de procedimientos, y casos especiales, más que en la rutina de asignación de tareas.

Los procedimientos son formalmente documentados y seguidos de forma exacta y estándar, asegurando que el trabajo es llevado a cabo en la forma planificada.

La persona adecuada, dispositivo o sistema es asignado a cada caso, y los casos más importantes o críticos en el tiempo, son asignados primero. Los usuarios no gastan tiempo escogiendo sobre cual caso trabajar, aplazando quizás aquellos más importantes pero de mayor dificultad.

Se logra el procesamiento paralelo, donde dos o más actividades no dependientes pueden ser realizadas concurrentemente, generando así beneficios en cuanto a reducción de tiempo de los procesos, mejor servicio al cliente y reducción de costes.

2.1.9 BPM (Business Process Managem ent )

2.1.9 .1 Int roducción a BPM

Gestión de procesos de negocio (BPM) es uno de los segmentos de mercado más importantes en la industria del software actualmente. BPM es una tecnología que permite a las organizaciones modelar, automatizar, administrar y optimizar los procesos

21

de negocios. BPM incluye la combinación correcta de dirección empresarial y tecnología, permite una reducción significativa en los ciclos de tiempos algunas veces hasta en un 90%. Esto es particularmente cierto para procesos que cruzan departamentos, aplicaciones y usuarios. Desde una perspectiva tecnológica, un sistema BPM independiente se puede integrar fácilmente con aplicaciones existentes, tales como CRM, ERP y ECM, sin que requiera de un rediseño total del sistema. Dependiendo del proceso, el BPM mejora la productividad, visibilidad y sensibilidad de la organización; reduce los costos, errores y acelera las duraciones de ciclo. En última instancia, un enfoque de mejoramiento BPM es un conductor dominante para la rentabilidad.

El BPM o Gestión de procesos de negocio es un conjunto de técnicas, actividades y tareas, bajo un enfoque metodológico o metodología, con el fin de gestionar los procesos de negocio. No obstante, se ha venido empleando el término BPM también para ir reemplazando el término WorkFlow, que está más asociado a tecnologías de los 90. También porque los WorkFlow han ido evolucionando e incorporando nuevas funcionalidades. La "Tecnología BPM", es la evolución de los Workflow y básicamente contempla:

Reglas de negocio robustas y flexibles a través de motores de reglas de negocio.

Arquitectura basada en Web.

Seguridad y autenticación de usuarios (LDAP u otros sistemas)

Asignación de actividades por "Roles" y dinámica

Gestión de timers dinámicos

Ejecución paralela de una misma actividad

Cambios a los procesos en caliente

Subprocesos y procesos encadenados

Ejecución dinámica de subprocesos

Reportes estadísticos y de monitorización.

Organización (Organigrama)

Integración con Servidores de Aplicaciones

Servicios del motor a través de Webservices

Además cada vez más se van ampliando estas características, y cada vez más se va necesitando menos código de programación. Otras características son: simulaciones, BPMN y BPML, enrutamiento por votación, administración de múltiples interfaces de clientes, gestión de documentos, asignación automática de actividades por diferentes destinos, etc. Estos proyectos no pueden estar enfocados únicamente en tecnología, y el enfoque tradicional de abordar un proyecto de desarrollo de sistemas no es suficiente para automatizar adecuadamente los procesos con tecnología BPM. Un factor crítico de éxito de estos proyectos es incorporar el BPM

22

al proyecto, y tener una o más personas que realmente visualicen y diseñen la solución orientada a procesos. Las aplicaciones de BPMS (Business Process Management) serán el mercado de más rápido crecimiento hasta el año 2011, excediendo los 1000 millones de dólares en el año 2007 hasta alcanzar 2600 millones en el 2011.

2.1.10 Hist or ia del BPM

La 1ª ola, se inicia en el s. XX y es dominada por la “teoría de la gestión” de Taylor, los procesos estaban implícitos en la práctica del trabajo y no automatizados. Fueron en gran parte procesos que reorganizaban las actividades de las personas. La 2ª ola, BPR (Business Process Reingeneering), son los años ’90, Fue el auge de la integración y la mejora de procesos del Negocio. Gracias a esto aparecieron los estándares el flujo de trabajo se volvió colaborativo y en muchos casos estaba embebido en las aplicaciones. Aparecen también tecnologías para integración como EIA y B2B y mejora la personalización. En la 3ª ola de la era de la información pasamos a la era del proceso, a partir del 2000 en adelante surgió BPM. La aparición de más estándares, la maduración del Middleware, los web services permitieron incrementar el grado de integración, la reusabilidad y la aceptación por parte de las organizaciones. Agilidad y adaptabilidad son las palabras clave: la cadena de valor se gestiona, se monitoriza, se mejora de forma continua, se modifica en tiempo real. En las dos primeras olas, ya se usaba el modelado de procesos de negocio pero sólo para fomentar la compresión humana y no para dirigir la gestión de los procesos de negocio, como actualmente se pretende

2.1.10.1 Im por t ancia del BPM

BPM (Gestión de los procesos de negocio) es de gran importancia ya que permite modelar la arquitectura empresarial orientándola a procesos, automatizando cada uno de ellos de principio a fin y estableciendo las metodologías necesarias para su monitorización y control. Frente a una organización tradicional en el que los Sistemas están centrados en los datos, se evoluciona con el enfoque BPM hacia unos Sistemas centrados en Procesos de Negocio que son modelados mediante Workflows. La implantación de BPM permite aprovechar las infraestructuras y sistemas existentes, de forma totalmente integrada, minimizando el impacto económico de los cambios. La agilización de procesos y reducción de costes mediante BPM se obtienen desde el primer momento, permitiendo monitorizar el negocio y detectar cualquier problema en la Gestión Empresarial, el ajuste a las métricas establecidas y el cumplimiento de los

23

parámetros de Calidad. Cambios de estrategia empresarial en una organización con BPM pueden ser ejecutados de forma inmediata sin implicar necesariamente nuevas inversiones en tecnología y permitiendo aplicar la reingeniería de procesos con un impacto mínimo en la Organización. BPM consigue que las Organizaciones, lejos de quedar atrapadas en una rigidez limitada por su propia tecnología, puedan renovarse, alcanzando el dinamismo necesario que los nuevos tiempos exigen. Pasos para el BPM

Workflow: Un Workflow o flujo de trabajo es una secuencia de tareas estructurada o semiestructurada ejecutada en serie o en paralelo por dos o más individuos.

EIA (Integración de Aplicaciones Empresariales): Es un sistema para automatizar el movimiento de datos entre aplicaciones y sistemas. Si una empresa cuenta con una serie de aplicaciones de distintos proveedores y no pueden intercambiar información de forma fácil y transparente, EAI puede ayudarle a integrar sus aplicaciones. Basado en arquitecturas flexibles y estándares ESB (Enterprise Service Bus) actúa como concentrador de la información que requiere ser integrada.

BPM (Business Process Management) es la unión de Workflow y EIA (Integración de Aplicaciones Empresariales).

Es una secuencia de tareas que son ejecutadas en serie o en paralelo por dos o más individuos o aplicaciones.

Es la “Interacción” de personas, aplicaciones, datos y documentos independiente de aplicaciones y arquitecturas (ver figura 6).

Figura 5 - BPM

Qué no es un BPM?

BPM no es un Workflow, es mucho más.

BPMS no es un aplicativo orientado a solucionar determinada casuística, es una solución mucho más genérica que nos permite modelar y poner en producción de una manera ágil y sencilla cualquier proceso de nuestra organización.

BPM no es una herramienta de desarrollo de aplicaciones.

Diferencias entre WORKFLOW Y BPM

BPM contempla soporte para interacción humana, e integración de aplicaciones, y es aquí la diferencia fundamental con la tecnología de WorkFlow existente, que es que BPM integra en los flujos a los sistemas.

24

Figura 6 - Integración BPM

Las soluciones del tipo WorkFlow solo se limitaban a definir el flujo de actividades humanas, o de documentos, y con esto obtener el seguimiento de los procesos, pero en estos casos si un participante del proceso requería como parte de sus actividades ingresar datos en una aplicación, entonces debía salir del ambiente del WorkFlow, levantar la aplicación, y luego de terminada su operación volver al WorkFlow y registrar el cambio de estado, o termino de la actividad. En BPM todo está integrado en el mismo flujo lo que es más natural para un participante, el completa su actividad dentro del flujo BPM, y tras bambalinas se actualizan los sistemas que se tengan que actualizar.

Con BPM se trata de proveer una sola interfaz para un participante del proceso, ocultando la interacción con los sistemas, mientras en un WorkFlow (tradicional) la persona debe interactuar con distintos ambientes o aplicaciones, dicho de otra forma: la persona debe manejar distintas aplicaciones (sistemas), y además registrar su avance en el WorkFlow. En la práctica un flujo BPM (o modelo de proceso BPM) visualmente es muy parecido a un WorkFlow, la diferencia está en que en que se puede notar que ciertas actividades son realizadas por personas, y otras son actividades sistematizadas (realizadas por sistemas), y ambas aparecen en el flujo. Otro “valor agregado” de BPM es que ofrece una solución completa, que abarca todo el ciclo de vida de un proceso de negocio: análisis, modelamiento, ejecución y monitoreo de los procesos. En BPM el modelo del proceso se convierte en el núcleo de la implementación del proceso como solución tecnológica. El modelo del proceso de negocio (el diseño), que realiza el área de negocios de una empresa, es “en si” lo que se ejecuta sobre el “servidor de procesos” (motor de BPM). Dicho en otras palabras: la “lógica de negocio” principal que antes bajo las tecnología tradicional se debía programar, y colocar sobre un “servidor de aplicaciones” (tradicional), ahora se reemplaza por un modelo que se sube al “servidor de procesos” con mucho menos intervención del área de TI (menos programación). Similitud entre WorkFlow y BPM con WorkFlow (al igual que BPM) se le da seguimiento y control a los procesos de negocio, es decir, podemos saber el estado actual de cada

25

proceso, en qué lugar del flujo se encuentra. Otra similitud con BPM, o dicho de otra forma; otra característica que BPM heredo de los WorkFlow, es que a través del proceso generalmente fluye información (documentos, datos), lo que se llama la metadata, u objeto de negocio (BPM).

2.1.10.2 Disciplinas de BPM

BPMN: Es el estándar para modelar los procesos de negocio. BPEL: Es el estándar para ejecutar procesos de negocio. BAM: Business Activity Monitoring (BAM), permite el monitoreo de actividades de negocio usando indicadores claves de desempeño. (Key Performance indicador KPI). BAM exige a una empresa identificar sus indicadores de rendimiento claves (KPI) SOA + ESB: Estilos de Arquitectura, que son la base para construcción de una infraestructura orientada en servicios y procesos.

Figura 7 - Disciplinas

SOA, EIA, ESB Con el auge de las tecnologías SOA (Service Orientated Architecture) y EDA (Event Driven Architecture) se perfila la necesidad de un nuevo componente en la ya compleja infraestructura de los servicios de información: el bus de servicios de empresa (ESB). Dicho componente viene a cubrir un espacio creado por la necesidad de permitir la comunicación entre componentes o servicios de la empresa.

Hasta la fecha, el papel de integrador venía dado de la mano de EAIs (Enterprise Application Integration), una tecnología que permitía comunicar distintos recursos informáticos para poder hacer uso de ellos conjuntamente. El problema que tiene esta tecnología es que los tiempos de desarrollo son largos, los proyectos conllevan un desembolso importante y existe una absoluta dependencia del fabricante.

Debido a esta difícil situación respecto a los EAIs, la industria ha evolucionado hacia lo que se ha pasado a llamar ESB. El corazón de un ESB es un MOM (Message-oriented Middleware); lo que permite que la comunicación entre distintos componentes se haga de manera transparente, fiable y asíncrona (en el caso de que fuese necesario el sincronismo también deberá permitirlo el ESB).

26

Además del sistema de mensajería hacen falta conectores para comunicar los distintos recursos de la empresa con el ESB. Dichos conectores permitirán exponer los recursos de la empresa como servicios web dentro del propio ESB (de hecho la definición de los mismos se queda en el nivel de abstracta, sin necesidad de definir los puertos). De manera que la comunicación interna del ESB se realiza con XML como formato impuesto, permitiendo con ello acceder de manera sencilla y rápida a la información que transita por dentro. Este último hecho permite aplicar tecnologías como BAM (Bussiness Activity Monitoring) sobre los datos que transitan por un ESB. Por último, pero no menos importante, es responsabilidad de un ESB el enrutamiento de los mensajes y la orquestación de los procesos. Por enrutamiento se entiende el proceso de recibir la entrada de un mensaje y decidir la salida o salidas que el mensaje debe tomar (pudiendo haber transformación del contenido, gracias al hecho de que es XML, se pueden usar tecnologías como XSLT). La orquestación es el esqueleto de una aplicación compuesta, en la que a través de lenguajes formales se permite definir el flujo de actividades y estados por los que ha de pasar un proceso de empresa para su realización (un ejemplo bastante extendido es BPEL).

Middleware es el software que conecta dos aplicaciones que de otra manera estarían separadas. Por ejemplo, hay varios productos de middleware que conectan una base de datos con un servidor web. Esto permite a los usuarios solicitar datos de la base de datos empleando formas o planillas desplegadas en un explorador web, y le permite al servidor web entregar páginas web dinámicas de acuerdo al interés del usuario o a su perfil.

BPMS (Business Process Management System) Presta apoyo en todo el ciclo de vida de los procesos de negocio, los elementos esenciales para un BPMS son (ver figura 13):

Herramientas gráficas para modelar los procesos.

Herramientas que permitan definir reglas de negocio, además que permitan integrarse fácilmente a otras tecnologías y plataformas. Y con un motor de workflow mediante el cual se gestione el flujo de estos procesos.

Herramientas que permitan tener una visión y control sobre lo que está ocurriendo en las distintas actividades y procesos del negocio y que permitan ajustar dinámicamente el comportamiento para adaptar mejor la realidad.

Herramientas de análisis que permitan aprender de lo ocurrido e identificar aquellas actividades y procesos que deben ser optimizados.

27

Figura 8 – Ciclo de vida BPM

2.2 Arquit ect ura Or ient ada a Servicios SOA: La arquitectura SOA, desde el punto de vista del negocio, ayuda a resolver los siguientes requerimientos, largamente reclamados por el área de negocio:

Mejora en los tiempos de realización de cambios en procesos.

Facilidad para evolucionar a modelos de negocios basados en tercerización.

Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores).

Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio

Facilidad para la integración de tecnologías disímiles

La arquitectura SOA permite a las organizaciones satisfacer las cambiantes necesidades de la empresa mediante la implantación de procesos de negocio que utilizan los servicios proporcionados por los sistemas actuales. La arquitectura garantiza la interoperabilidad de los sistemas a pesar de que, en gran parte, hayan sido construidos en distintos momentos, con diferentes intenciones, plataformas y niveles de servicio, y a pesar del hecho de que ahora se encuentren en distintos ciclos de mantenimiento, mejora y presupuesto. Anteriores estrategias de integración entraban en conflicto con estas realidades, pero ahora la arquitectura SOA ofrece un modo de enfrentarse mejor a ellas y de aumentar los niveles de agilidad y flexibilidad. La sencillez interna proporciona a la organización la agilidad necesaria para crear nuevos productos y servicios de una forma más fácil y rápida, y le permite así diferenciarse en el mercado. La diferenciación competitiva resulta esencial para la mayoría de los sectores, y la arquitectura SOA proporciona los elementos necesarios para que las organizaciones alcancen con éxito el alto rendimiento. SOA define las siguientes capas de software:

28

Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o

tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;

De exposición de funcionalidades - Donde las funcionalidades de la capa

aplicativa son expuestas en forma de servicios (generalmente como servicios

web);

De integración de servicios - Facilitan el intercambio de datos entre elementos

de la capa aplicativa orientada a procesos empresariales internos o en

colaboración;

De composición de procesos - Que define el proceso en términos del negocio y

sus necesidades, y que varía en función del negocio;

De entrega - donde los servicios son desplegados a los usuarios finales.

2 .2 .1 Term inología SOA

Término

Definición / Comentario

Servicio Una función sin estado, auto-contenida, que acepta una(s)

llamada(s) y devuelve una(s) respuesta(s) mediante una interfaz

bien definida. Los servicios pueden también ejecutar unidades

discretas de trabajo como serían editar y procesar una

transacción. Los servicios no dependen del estado de otras

funciones o procesos. La tecnología concreta utilizada para prestar

el servicio no es parte de esta definición. Existen servicios

asíncronos en los que una solicitud a un servicio crea, por ejemplo,

un archivo, y en una segunda solicitud se obtiene ese archivo

Orquestación Secuenciar los servicios y proveer la lógica adicional para procesar

datos. No incluye la presentación de los datos. Coordinación.

Sin Estado No mantiene ni depende de condición pre-existente alguna. En

una SOA los servicios no son dependientes de la condición de

ningún otro servicio. Reciben en la llamada toda la información que

necesitan para dar una respuesta. Debido a que los servicios son

"sin estado", pueden ser secuenciados (orquestados) en

numerosas secuencias (algunas veces llamadas tuberías o

pipelines) para realizar la lógica del negocio.

Proveedor La función que brinda un servicio en respuesta a una llamada o

petición desde un consumidor.

Consumidor La función que consume el resultado del servicio provisto por un

proveedor

Enlazamiento (Binding).

Comunicación entre dos componentes de software.

Enlace estándar sin importar el protocolo de comunicación

29

usado.

o HTTP o JMS o REST o SOAP

Tabla 3 – Terminología SOA

2.3 Diseño y Desar rollo SOA

La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura. Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen los siguientes:

XML

HTTP

SOAP

WSDL

UDDI

Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser "Orientado a Servicios" pero es altamente recomendable su uso. En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios.

2 .3 .1 Cont rat o de Servicio

Un contrato de servicio está comprendido de uno o más documentos publicados (llamados documentos descriptivos de los servicios) que expresan la meta información acerca de un servicio. La parte fundamental de un contrato de servicio consiste de documentos descriptivos que expresan su interfaz técnica. Estos conforman el contrato

http://es.wikipedia.org/wiki/XMLhttp://es.wikipedia.org/wiki/HTTPhttp://es.wikipedia.org/wiki/SOAPhttp://es.wikipedia.org/wiki/WSDLhttp://es.wikipedia.org/wiki/UDDIhttp://es.wikipedia.org/wiki/Servicio_Webhttp://es.wikipedia.org/wiki/SOAPhttp://es.wikipedia.org/wiki/WSDL

30

de servicio técnico el cual establece esencialmente una API para la funcionalidad ofrecida por el servicio. Cuando se implementan servicios como servicios web, los documentos descriptivos más comunes son la definición WSDL (Web Services Description Language), la definición de esquemas XML, y la definición de WS-Policy. Generalmente, un servicio web sólo tiene una definición WSDL, que puede estar enlazada a múltiples esquemas XML y definiciones de políticas. Cuando se implementan los servicios como componentes, el contrato de servicio técnico está comprendido de la API específica de la tecnología. Un contrato de servicio puede además estar comprendido de documentos legibles por los humanos, tales como el Acuerdo de Nivel de Servicio (SLA) que describe rasgos adicionales acerca de la calidad de servicio, comportamiento y limitaciones.

Dentro de la orientación a servicios, el diseño del contrato de servicio es de máxima importancia. Tan así que existe un proceso de diseño específico dedicado exclusivamente a la estandarización de la creación de los contratos de servicios.

Figura 9 – Contrato de Servicios

2.3.2 Servicios Web

La adopción de una solución de diseño basada en SOA no exige implantar servicios Web. No obstante, los servicios Web son la forma más habitual de implementar SOA. Los servicios Web son aplicaciones que utilizan estándares para el transporte, codificación y protocolo de intercambio de información. Los servicios Web permiten la intercomunicación entre sistemas de cualquier plataforma y se utilizan en una gran variedad de escenarios de integración, tanto dentro de las organizaciones como con partners de negocios. Los servicios Web se basan en un conjunto de estándares de comunicación, como son XML para la representación de datos, SOAP (Simple Object Access Protocol) para el intercambio de datos y el lenguaje WSDL (Web Services Description Language) para describir las funcionalidades de un servicio Web. Existen más especificaciones, a las que se denomina genéricamente como la arquitectura WS-*, que definen distintas funcionalidades para el descubrimiento de servicios Web, gestión de eventos, archivos adjuntos, seguridad, gestión y fiabilidad en el intercambio de mensajes y transacciones.

31

Figura 10 – Tecnologías Orientadas a Servicios

2.4 Bus de int egración de servicios corporat ivos

(Ent erpr ise Service Bus) Las soluciones ESB son el resultado de aplicar el patrón EAI a la arquitectura orientada a servicios (SOA).Una solución de EAI o Integración de Aplicaciones Empresariales consiste en: Comunicar las diferentes aplicaciones mediante conectores, tanto dentro de la organización como interorganizativas. La grandeza de una solución de ESB está en posibilitar que la comunicación entre sistemas sobre cualquier protocolo. Es decir, se convierte en una pasarela, que se encarga de traducir de un lenguaje a otro. Por otro lado, el lenguaje que utilizan los sistemas con el bus se normaliza, empleándose lenguaje XML. Gracias al ESB los servicios no interactúan directamente, sino que la comunicación es a través de un conector. El ESB proporciona la vitalización de los servicios: Ubicación e Identidad: El ESB identifica y establece las rutas de los mensajes entre los servicios, de manera que éstos no tienen por qué conocer la ubicación o la identidad de otros participantes en la comunicación. Protocolo de comunicación: El ESB permite el flujo de mensajes a través de diferentes protocolos de transporte o los estilos de interacción (HTTP, FTP, SMTP). En definitiva, las funciones de un ESB son:

Identificar los mensajes y las rutas entre los servicios Permitir el flujo de mensajes a través de diferentes protocolos de transporte (HTTP, FTP, SMTP)

Transformar los formatos de los mensajes entre el solicitante y el servicio

Proporcionar robustez y seguridad de las comunicaciones.

Proporcionar enrutamiento inteligente y ubicación independiente de la transformación.

http://www.xperimentos.com/2009/02/03/bus-de-integracion-de-servicios-corporativos-enterprise-service-bus/http://www.xperimentos.com/2009/02/03/bus-de-integracion-de-servicios-corporativos-enterprise-service-bus/

32

Figura 11 – Arquitectura ESB

33

CAPITULO 3.

3 Det alle de la f ase de análisis t radicional y análisis

con BPM

3.1 Met odología Análisis Tradicional

La metodología de desarrollo que tiene definida la empresa Extras y Eficacia para el análisis de los desarrollos de software, se puede clasificar como tradicional y se divide en cuatro fases:

Fase Levantamiento: La inicia el usuario escribiendo la necesidad o problemática en una plantilla creada para ello llamada MD050.

Fase Aclaración: El ingeniero de gestión de requerimientos recibe de parte del usuario líder del proceso, el requerimiento detallado en el MD050. El ingeniero de gestión de requerimiento lee el documento y solicita al usuario que se reúnan para aclarar la necesidad, esto en el caso que se identifique que hay ambigüedad o se detecta que no está completo. Una vez aclarado el requerimiento se pasa a la fase siguiente.

Fase Análisis: El ingeniero de desarrollo software asignado para administrar el requerimiento se reúne con el Ingeniero de gestión de requerimientos para hacer la entrega formal y leer en conjunto la necesidad y así determinar si se recibe a satisfacción o si es necesario que se complemente algunos puntos. Una vez recibido a satisfacción el requerimiento por parte del equipo de desarrollo, se inicia el análisis detallado, teniendo el documento MD050 de base para identificar cada uno de los componentes de desarrollo, los cuales se relacionan en un archivo de Excel llamado RTM (Matriz trazable de requerimientos).

Teniendo claro los componentes de desarrollo de software se da inicio al análisis detallado, el cual debe quedar escrito en el documento llamado MD060, en ese documento quedan registrados la funcionalidad, restricciones, excepciones, procesos alternos o paralelos que se derivan de cada componente de desarrollo. Al final se definen los tiempos requeridos para la construcción.

Fase de Validación: Finalizado el análisis se convoca a una reunión al ingeniero de gestión de requerimientos, el usuario líder del requerimiento y el analista de desarrollo de software. En la reunión se hace la presentación de la(s) alternativa(s) de solución y entre todos se selecciona una de ellas. El usuario líder da visto bueno de la propuesta seleccionada y se inicia la fase de diseño y construcción.

34

3.1.1 Def inición Cronogram a m ét odo t radicional

Figura 12 – Cronograma Análisis con Método Tradicional

3.1.2 Análisis subproceso de gest ión de hojas de vida

El análisis del subproceso de gestión de hojas de vida está registrado en el anexo 1

3 .1 .2 .1 Diagram as de Casos de uso (Sit uación Act ual)

3.1.2 .1 .1 Fuent es de Reclut am ient o Hojas de Vida

Figura 13 – Caso de Uso Fuentes de Reclutamiento

35

3.1.2 .1 .2 Gest ión Hojas de Vida

Figura 14 - Caso de Uso Gestión de Hojas de Vida

3.1.2 .1 .3 Cargues m asivos Hojas de Vida

Figura 15 - Caso de Uso Cargues masivos de Hoja de Vida

36

3.1.2 .2 Modelo Concept ual del Sist em a

Figura 16 – Modelo Conceptual

3 .2 Análisis Proceso Act ual con BPM

3.2.1 Análisis con BPM

Las herramientas BPM permiten agilizar el proceso de análisis en empresas que tienen definidos sus procesos, subprocesos, actividades y tareas que ejecuta cada rol y persona que participa en la cadena valor ya sea de forma manual o automática.

Figura 17 – Mapa de procesos empresa Extras y Eficacia

37

La empresa Extras y Eficacia, al tener los procesos estructurados y definidos se le facilitará la implementación de la tecnología BPM y le permitirá gestionar sus procesos de negocio de principio a fin, estableciendo metodologías para monitorización y control a través de la integración de procesos, flujos de trabajo, reglas de negocio, aplicaciones y servicios Web. Las personas que participaran en el proceso de análisis con BPM serán:

Líder del proceso o subproceso

Ingeniero de Gestión del requerimiento

Con esta nueva tecnología de BPM el Ingeniero de Análisis detallado y diseño no es involucrado ya que la redefinición de procesos y subproceso van quedando definidos de forma detallada con la relación de las aplicaciones e integraciones que se deben llevar a cabo en la redefinición o reestructuración del proceso o subproceso.

3 .2 .2 Def inición Cronogram a Análisis con BPM

Figura 18 – Cronograma Análisis con BPM

3.2.3 Análisis m odelo BPM

El análisis con la tecnología BPM se realizará llevando a cabo cada una de las siguientes actividades:

3.2.3 .1 Descubr im ient o del subproceso de gest ión de hoja s de vida:

Para dar inicio al análisis con BPM, primero se debe conocer el proceso de preselección de talentos que tiene el objetivo de poder buscar hojas de vida para poderlas asociar a los diferentes cargos de la empresa Extras y Eficacia que puede cubrir cada candidato de acuerdo a los conocimientos, estudios y experiencias laborales que presente en su hoja de vida.

38

Una vez conocido el proceso de preselección de talentos el análisis se enfocara en el subproceso de gestión de hojas de vida que se llevará a cabo en el portal web www.buscojobs.com.co

Figura 19 – Diagrama de flujo proceso de preselección de talento

3.2.3 .2 Modelam ient o del f lujo act ual de l subproceso de gest ión de

hojas :

Para realizar el flujo del proceso se definen los roles y actividades que intervienen en el proceso de gestión de hojas de vida en el subproceso actual. Roles:

Fuentes de reclutamiento hojas de vida

Área de reclutamiento

Área de selección

Área de contratación Actividades:

Recibir hoja de vida

Verificar y validar hoja de vida

Grabar hoja de vida

Descartar hoja de vida

Definir estado hoja de vida sistema ADAM

3.2.3 .2 .1 Workf low subpr oceso act ual

Definición de flujo de proceso actual usando la herramienta BPM www.blueworkslive.com de IBM Corporation.

http://www.buscojobs.com.co/http://www.blueworkslive.com/

39

Figura 20 – WorkFlow subproceso actual

3.2.3 .2 .2 Diagram a act ual de áreas de l subproceso y act iv idades de

hoja de vida

Al analizar el flujo del proceso actual con la herramienta BPM se puede observar la carga de actividades por cada uno de los roles que participan en el subproceso.

Figura 21 - Diagrama de Áreas del subproceso y sus Actividades

40

3.2.3 .3 Def inición de las reglas de negocio para la gest ión de hojas

de vida: En el proceso actual hay una regla de negocio definida pero se hace el control manualmente y a criterio del analista de reclutamiento o de selección, la validación que se hace es verificar si la hoja de vida que entrego el candidato cumple con algún perfil para grabarla en el sistema ADAM y si no cumple archivarla.

3.2.3 .4 Mejoram ient o del f lujo del subproceso:

El análisis inicia definiendo los roles y actividades que se realizaran con el nuevo modelo de creación y actualización de las hojas de vida que se hará a través del portal www.buscojobs.com.co Roles:

Portal de hojas de vida www.buscojobs.com.co

Sistema integrador

Sistema ADAM Actividades:

Registrar hoja de vida

Verificar y validar hoja de vida

Integrar hoja de vida

Grabar hoja de vida sistema ADAM

Definir estado hoja de vida sistema ADAM

3.2.3 .4 .1 Workf low proceso propuest o

Definición de flujo de proceso propuesto usando la herramienta BPM www.blueworkslive.com de IBM Corporation.

http://www.buscojobs.com.co/http://www.buscojobs.com.co/http://www.blueworkslive.com/

41

Figura 22 – WorkFlow Proceso Propuesto

3.2.3 .4 .2 Diagram a de áreas de proceso y act iv idades

Al analizar el flujo del proceso propuesto con la herramienta BPM se puede observar la carga de actividades por cada uno de los roles que participan en el subproceso.

Figura 23 – Diagrama de Áreas de Procesos y sus Actividades

42

CAPITULO 4.

4 Análisis com parat ivo de m odelos t radicional y

BPM

4.1 Tiem pos inver t idos por f ase

Los tiempos que se detallan en la Figura 23 relacionan los tiempos medidos en horas que fueron requeridos para llevar a cabo la fase de Análisis funcional y detallado de la solución entregada con el modelo de análisis tradicional y el modelo de análisis con una herramienta BPM. Al comparar las actividades realizadas y la cantidad de horas invertidas en cada uno de los modelos, se puede ver claramente la diferencia tanto en cantidad de actividades y número de horas totales. El modelo tradicional en la fase de análisis requiere de 6 Actividades con un total de 53 horas y con el modelo BPM las actividades se reducen a 4 y la inversión en horas disminuye a 35. Lo anterior nos lleva a concluir que la productividad de la fase de análisis con el modelo BPM se incrementa en este caso, en 18 horas y se disminuye en 2 actividades y lo más importante es que la calidad del análisis se mantiene.

Figura 24 – Diagrama comparativo de tiempos invertidos por fase

43

4.2 Tiem pos inver t idos por rol Uno de los recursos más importantes en la planeación de un proyecto es el recurso humano y el tiempo definido para su desarrollo. Las personas asignadas al proyecto con las que se realiza el estudio comparativo, las tomamos con base en el modelo Tradicional. Podemos especificar como roles y funciones importantes en la etapa de análisis: 1: Líder de Talento Humano 2: Analista de Talento Humano 3: Analista de Productividad y Desarrollo 4: Ingeniero de Gestión y Requerimientos 5: Analista de Desarrollo 6: Coordinador de Procesos de Desarrollo Al realizar el análisis comparativo podemos observar a partir de la figura 25, que aplicando el modelo BPM salen de la lista los roles de analista de Desarrollo y el de Coordinador de Procesos de Desarrollo, ya que sus tareas en esta fase no aplican para su función dentro del proyecto. También observamos la variación en cuanto a la cantidad de horas trabajadas por rol en cada modelo, concluyendo que en la aplicación del modelo BPM se consumen menos horas en total pero se concentran más actividades en los roles de Analista de Productividad y el de Ing. De Gestión y Requerimientos. Así mismo conseguimos validar que la actuación del rol de Analista de Talento Humano que corresponde al área cliente tiene una mayor participación.

Figura 25 – Diagrama comparativo de tiempos invertidos por rol

44

4.3 Esf uerzo en días

Siendo consecuentes con la observación anterior con respecto al tiempo por rol, en la proyección en días para la etapa de análisis del proyecto podemos observar un mayor esfuerzo en el modelo tradicional (53 días) a diferencia del modelo BPM (33 días) como lo muestra la figura 26.

Figura 26 – Diagrama comparativo de esfuerzo en días

4.4 Núm ero de personas Validando el tema de cantidad de recurso en cuanto a personas en el proyecto, aplicando el modelo tradicional tenemos en principio que se asigna una persona por rol es decir, se destina en total, un número de 6 personas que intervienen en la etapa de análisis. Siendo consecuentes con esta forma de asignación de las tareas, aplicando el modelo BPM solo se requerirían en sentido estricto 4 personas (Ver figura 27- Diagrama comparativo de Recursos en # de Personas). Sin embargo, de acuerdo al punto 4.2 Tiempos invertidos por rol observamos una concentración de las actividades en los roles de Ing. De Gestión de Requerimientos y de Analista de Productividad, para los cuales es posible asignar más personas que cumplan estos roles, evitar la sobrecarga y rutas críticas sin aumentar la cantidad de horas asignadas para cumplir con las actividades a realizar, en consecuencia, se conseguiría no alargar el tiempo total del proyecto aplicando el modelo BPM.

Figura 27 – Diagrama comparativo de Recursos en # de Personas

45

4.5 Cost os del recurso Tanto en el modelo tradicional como en el modelo BPM se ejecutan una serie de actividades definidas en cada etapa del desarrollo de un proyecto de software. Al compararlos en cuanto a costos del recurso asignado y coherente a la información presentada en los puntos anteriores, podemos visualizar en la siguiente figura 28 un mayor costo presupuestado para el desarrollo de la etapa de análisis con el modelo tradicional (una diferencia de $9.737.762 con respecto al del modelo BPM).

Figura 28 –Diagrama comparativo de Costos

4.6 Tareas Cr ít icas

Con Modelo Tradicional

La ruta critica se plantea de forma serial en los diferentes roles que participan en el proyecto, lo cual hace que el porcentaje de oportunidad se pueda ver afectado por diferentes eventualidades.

46

Figura 29 – Diagrama de Tareas Críticas con Modelo

Con BPM La ruta crítica solo se encuentra en el rol de Ing.de Gestión y Requerimientos por lo tanto el riesgo es menor y se puede tener un mejor control de las eventualidades que puedan afectar la oportunidad del proyecto.

Figura 30 – Diagrama de Tareas Críticas con BPM

4.7 Com parat ivo ent re los m odelos de est udio en la f ase

de Análisis

Modelo Tradicional Modelo BPM

Las actividades en la fase de análisis requieren mayor número de actividades.

Se reducen las actividades de análisis.

Las fases de análisis y diseño son independientes

Se unifican las fases de análisis y diseño.

Se requiere mayor cantidad de personas para llevar a cabo la fase de análisis y diseño.

La fase de análisis y diseño se realizan con una misma persona.

Este modelo se enfoca hacia la gestión de datos.

Este modelo se enfoca hacia la gestión de proceso.

La participación de usuario final es delimitada en algunas actividades.

Existe mayor participación y continuidad del usuario final con el proceso.

47

La documentación es independiente La documentación se va generando a medida que el proceso se va modelando.

El mejoramiento del sistema se desarrolla al final de cada fase.

El mejoramiento se lleva a cabo en las diferentes iteraciones del proceso.

Los nuevos requerimientos generan mayor impacto de implementación.

Los nuevos requerimientos se implementan de una manera rápida y flexible.

No se aleja de la tradicional concepción de las aplicaciones pues no se tiene en cuenta el proceso no se tiene en cuenta el negocio.

Se enfoca en el negocio se tiene una visión de las características del negocio.

El modelo contiene las fases de Análisis, Diseño, Construcción e implementación.

El modelo contiene fases de Modelamiento, análisis, monitoreo integración, automatización.

Existe una mayor cantidad de tareas críticas durante el desarrollo de la fase.

Disminuye el número de tareas criticas en el desarrollo de la fase

Tabla 4 – Comparativo entre los modelos de estudio en la fase de análisis

48

CAPITULO 5

5 Diseño Sist em a Int egrador de Int e r f aces El análisis de gestión de hojas de vida permite proponer a la empresa Extras y Eficacia de implementar un sistema que se integre de forma organizada y controlada con otros sistemas externos y poder mantener actualizada su base de datos de hojas de vida con la información que se registre en los portales web con los cuales se establezca convenio para la búsqueda de personal. Las características del sistema integrador se entregaron a una empresa experta en servicios de integración usando tecnología ESB y SOA y la arquitectura diseñada se presenta en la figura 31.

5.1 Diseño de Arquit ect ura para la int egración de servicios

SOA

Figura 31 – Diseño de Arquitectura SOA para la integración de servicios SOA

49

5.2 Caract er íst icas de los servicios

Eficacia ofrecerá los servicios de integración a través de un ESB (instalado en los

Datacenter de Eficacia) en donde se expondrán 2 puntos de integración:

o WebServices (SOAP/HTTP)

o SFTP

El ESB contará con un cluster para ofrecer redundancia en el ofrecimiento del

servicio.

BuscoJobs Consumirá los servicios por cualquiera de los puntos de integración.

Inicialmente se contará con:

SOAP/HTTP para realizar las notificaciones unitarias

SFTP para realizar las cargas masivas de notificaciones

El ESB encolará las solicitudes entrantes y salientes con el fin de garantizar

entrega fiable de mensajes origen-destino.

BuscoJobs ofrecerá el(los) contrato(s) y la(s) implementación(es) de los servicios

Web para ser notificado desde el sistema GCE.

50

CAPITULO 6.

6 TRABAJO FUTUROS

Los trabajos futuros de esta propuesta podrán enfocarse en el desarrollo de los ciclos de vida del modelo BPM:

Automatización: Permite reducir errores, asegurando que los procesos se comporten siempre de la misma manera y dando elementos que permitan visualizar el estado de los mismos.

Administración: Gestión y monitoreo de los procesos para permitir asegurar que los procesos estén ejecutándose eficientemente y obtener información que luego puede ser usada para mejorarlos.

Optimización: A través de la información que se obtiene de la ejecución diaria de los procesos se puede identificar posibles ineficiencias en los mismos y de esta forma optimizarlos.

Integración: Permitir que las demás plataformas utilizadas en diferentes proyectos se integren de forma fácil, permitiendo explorar las ventajas de la tecnología BPM.

51

CAPITULO 7.

7 CONCLUSIONES

1. En el comparativo de tiempos invertidos por cada fase podemos evidenciar que el

desarrollo del caso de estudio por el modelo tradicional conlleva más tiempo que realizándolo con la metodología BPM (53 días modelo tradicional vs. 33 días con BPM). También podemos concluir que en cuanto a número de actividades involucradas en la fase de análisis con el modelo BPM se reducen sin desmejorar la definición de los requerimientos.

2. Al revisar los tiempos presupuestados por rol, encontramos que existen roles a los cuales no se les involucra cuando se trabaja con BPM, por ejemplo el Analista de Desarrollo y el Coordinador de Procesos de Desarrollo. Para los demás el que más carga de trabajo tiene es el ingeniero de Gestión de requerimientos para ambos modelos, siendo con BPM la asignación menor. También podemos observar que con BPM hay roles con más funciones y responsabilidades, por ende más carga como es el caso del Analista de Productividad.

3. En cuanto a esfuerzo en días y costos de recursos, el modelo tradicional resulta más costoso para nuestro caso de estudio (6 personas requeridas en la fase de análisis vs. 4 y un incremento de $9.737.762 con respecto al modelo BPM)

4. La ruta crítica es más ajustada y secuencializada en el modelo tradicional, mientras que en la planeación con BPM y SOA permite tareas en paralelo más fácilmente observando que solo la tarea realizada por el ingeniero de requerimientos requiere de actividades predecesoras. Esto hace que con BPM haya más flexibilidad en la coordinación y ejecución de las tareas y disminuyen el número de tareas críticas en el desarrollo de la fase de análisis.

5. Las fases de análisis y diseño son independientes en el modelo tradicional mientras que con BPM estas fases se unifican.

6. El modelo tradicional se enfoca hacia la gestión de datos y el modelo BPM hacia la gestión de procesos lo que permite ver las necesidades y requerimientos de los clientes de una manera clara, rápida y sencilla.

7. Con el modelo de BPM y la implementación de SOA, se permite desde el análisis realizar una propuesta de integración con otras plataformas, con sistemas legados permitiendo aprovechar en un gran porcentaje su funcionamiento y

52

ventajas, además de utilizarlos funcionalmente sin necesidad de invertir esfuerzos en nuevos desarrollos.

8. El mejoramiento con BPM y SOA se lleva a cabo en las diferentes iteraciones del proceso mientras que con el modelo tradicional solo se permite al final.

9. Se recomienda para el caso de estudio, contar con una arquitectura de integración de servicios SOA dada la flexibilidad que brinda para integrarse con nuevas plataformas, tecnologías y sistemas diversos. La arquitectura orientada a servicios SOA permite organizar y mantener los sistemas abiertos y que se adapten fácilmente al mundo cambiante de los negocios con integraciones que soporten las nuevas necesidades de las empresas de poderse conectar con entes externos para recibir y entregar información que puede ser reutilizada por otros sistemas de información. Para hacer realidad un SOA se debe contar con varios componentes que al entrar en interacción logran el objetivo de integrar los negocios, procesos y servicios los cuales están siendo orquestados en sintonía para lograr el objetivo. Entre los componentes que hacen parte de esta orquestación esta el ESB el bus de servicios empresariales, el registro de SOA, el motor de Flujo de trabajo, el servicio agente y el supervisor de SOA.

53

8. GLOSARIO

8 GLOSARIO

Actividad: Conjunto de acciones que se llevan a cabo para cumplir un objetivo determinado. ADAM: Sistema integral de nómina y recursos humanos. API (Application Programming Interface): constituye un conjunto de rutinas, procedimientos, protocolos, funciones y herramientas que una determinada biblioteca pone a disposición para que sean utilizados por otro software como una capa de abstracción. En otras palabras, es una interfaz que permite la comunicación entre distintos componentes software. BAM (Business Activity Monitoring): permite el monitoreo de actividades de negocio usando indicadores claves de desempeño. Binding: Define un enlace que conecta las propiedades de destinos de enlace y de orígenes de datos. BPEL (Business Process Execution Language): Lenguaje de Ejecución de Procesos de Negocio. Consiste en un lenguaje basado en XML diseñado para el control centralizado de la invocación de diferentes servicios Web, con cierta lógica de negocio añadida que ayudan a la programación en gran escala BPM (Business process management): Gestión de los procesos de