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 Ob je t iv o Ge n e r a l
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 Ob je t iv os Esp e cí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 : Pla n e a ció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 : Eje cució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 Te or ía d e Pr oce sos
2 .1 .1 In t r od u cción a los p r oce sos
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 De f in ición d e los p r oce sos
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 Ca r a ct e r íst ica s d e los Pr oce sos
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 p on e n t e s d e los p r oce sos
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 Tip os d e p r o ce sos
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 Ge st ión p or p r oce sos
2 .1 .6 .1 In t r od u cción a la g e st ión p or p r oce sos
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 De f in ición d e g e st ión p or p r oce sos
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 e r e n cia s e n t r e g e st ión p or f un cion e s y g e st ión p or p r oce sos
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 Pa sos p a r a g e st ión p or p r oce so s 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 Le v an t am ie n t o d e p r oce sos
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 M a p e o d e Pr oce so s
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 b olog ía ut iliza d a p a r a r e p r e se n t a r p r oce sos
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 M od e la d o d e p r oce sos
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 W or k f 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 (Busin e ss Pr o ce ss M a n a g e m e n t ) 2 .1 .9 .1 In t r od u cció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 .1 0 Hist or ia d e l 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 .1 0 .1 Im p or t a n cia d e l 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 .1 0 .2 Discip lin a s d e 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 Ar q uit e ct ur a Or ie n t a d a a Se r v icios 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 Te r m in olog í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 De sar r ollo 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 Con t r a t o d e Se r v icio
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
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 Se r v icios W e b
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 d e in t e g r a ción d e se r v icios cor p or a t iv os (En t e r p r ise Se r v ice 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.
32
Figura 11 – Arquitectura ESB
33
CAPITULO 3.
3 De t alle d e la f ase d e a n álisis t r ad icio n a l y an álisis co n BPM
3 .1 Me t od olog ía An á lisis Tr a d icion a l
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 De f in ición Cr o n o g r a m a m é t od o t r a d icio n a l
Figura 12 – Cronograma Análisis con Método Tradicional
3 .1 .2 An á lisis sub p r o ce so d e g e st ión d e h oja s d e v id a
El análisis del subproceso de gestión de hojas de vida está registrado en el anexo 1
3 .1 .2 .1 Dia g r a m a s d e Ca sos d e uso (Sit ua ción Act ua l) 3 .1 .2 .1 .1 Fue n t e s d e Re clut a m ie n t o Hoja s d e Vid a
Figura 13 – Caso de Uso Fuentes de Reclutamiento
35 3 .1 .2 .1 .2 Ge st ión Hoja s d e Vid a
Figura 14 - Caso de Uso Gestión de Hojas de Vida
3 .1 .2 .1 .3 Ca r g ue s m a siv os Hoja s d e Vid a
Figura 15 - Caso de Uso Cargues masivos de Hoja de Vida
36 3 .1 .2 .2 M od e lo Co n ce p t u a l d e l Sist e m a
Figura 16 – Modelo Conceptual
3 .2 An á lisis Pr oce so Act ua l 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 De f in ición Cr on og r a m a An á lisis con BPM
Figura 18 – Cronograma Análisis con BPM
3 .2 .3 An á lisis m od e lo BPM
El análisis con la tecnología BPM se realizará llevando a cabo cada una de las siguientes actividades:
3 .2 .3 .1 De scub r im ie n t o d e l sub p r o ce so d e g e st ión d e h o ja s d e v id a : 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 M od e la m ie n t o d e l f lujo a ct ua l d e l sub p r oce so d e g e st ión d e h oja s :
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 W or k f low sub p r o ce so a ct ua l
Definición de flujo de proceso actual usando la herramienta BPM www.blueworkslive.com de IBM Corporation.
39
Figura 20 – WorkFlow subproceso actual
3 .2 .3 .2 .2 Dia g r a m a a ct ua l d e á r e a s d e l sub p r oce so y a ct iv id a d e s d e h oja d e v id a
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 De f in ición d e la s r e g la s d e n e g ocio p a r a la g e st ión d e h oja s d e v id a :
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 M e jor a m ie n t o d e l f lujo d e l sub p r o ce so:
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 W or k f low p r o ce so p r op ue st o
Definición de flujo de proceso propuesto usando la herramienta BPM www.blueworkslive.com de IBM Corporation.
