Cf Campothesis Cv

7/24/2019 Cf Campothesis Cv

1/74

UNIVERSIDAD DE CHILEFACULTAD DE CIENCIAS FSICAS Y MATEMTICASDEPARTAMENTO DE CIENCIAS DE LA COMPUTACIN

DISEO E IMPLEMENTACION DE UN

SISTEMA DE PLANIFICACION DE PERSONALMEMORIA PARA OPTAR AL TTULO DE INGENIERO CIVIL EN COMPUTACIN

CSAR MAURICIO CAMPOS VALENZUELA

PROFESOR GUA:

SERGIO OCHOA DELORENZI

MIEMBROS DE LA COMISIN:

CRISTIAN CORTS CARRILLO

CECILIA BASTARRICA PIEYRO

SANTIAGO DE CHILE

2013


2/74

ii

RESUMEN DE LA MEMORIA PARA OPTAR AL

TITULO DE: Ingeniero Civil en Computacin

Por: Csar Mauricio Campos Valenzuela

Fecha: 03-09-2013

Profesor Gua: Sergio Ochoa Delorenzi

DISEO E IMPLEMENTACIN DE UN SISTEMA DE PLANIFICACIN DE PERSONAL

Organizar los turnos de los empleados en regmenes de trabajo rotativos, es uno de los

grandes temas a resolver para las empresas que mantienen tal modalidad de trabajo, debido a

que esto requiere experiencia tanto para predecir las necesidades de personal a cierta hora,

como para asignar turnos que cumplan con las restricciones necesarias. Dichas restricciones,

que pueden ser legales, sindicales o provenir de necesidades especficas de cada empleado o

tarea, deben ser satisfechas completamente. A medida que crece el grupo humano al que se

desea organizar, se vuelve cada vez ms complicado poder cumplir con tales requerimientos a

cabalidad, especialmente si dicha labor se realiza mediante un proceso manual. Actualmente, laempresa Andes Airport Services se encuentra en el punto en que sus procedimientos de

asignacin de turnos estn comenzando a mostrar problemas. El tiempo de bsqueda de una

solucin alcanza las tres semanas, y no cumple con todas de las restricciones pertinentes.

Este problema surge cuando el tamao o la complejidad de la entrega de turnos supera la

capacidad manual de asignacin. Para solucionar lo anterior existen tanto modelos matemticos

especficos, como software especializado. Sin embargo estas soluciones son o bien costosas o

bien necesitan de especialistas capaces de ingresar y leer los resultados obtenidos. Es por esto

que la empresa busc desarrollar una solucin tecnolgica hecha a la medida de susnecesidades.

La solucin presentada en esta memoria corresponde a un sistema que permite realizar las

asignaciones de personal considerando turnos, cargos y restricciones legales, sindicales y de

RRHH. Adems, el sistema es capaz de entregar la asignacin completa de cada trabajador para

un mes dado, en tiempos de ejecucin razonables. El resultado de esta asignacin es editable y

se acopla al proceso actual de entrega de turnos para los empleados de la empresa. Cabe hacer

notar que la asignacin de turnos propiamente tal, es realizada por un modelo matemtico

ajeno al alcance de la memoria.

Para lograr esta solucin, se desarroll una aplicacin Web utilizando las tecnologas

provistas por Oracle ADF y estructuras de datos para el manejo de la informacin. Como

resultado del uso de este sistema se redujo el tiempo de generacin de los turnos y su tiempo

de edicin, sin descuidar la calidad de vida de los trabajadores.


3/74

iii

A todos los que me apoyaron durante

el tiempo que me tomo terminar mi

carrera: mi familia, mis amigos, los que

estn y los que se fueron, y a mi pareja.

Muchas gracias, si no fuera por su

ayuda, jams hubiese llegado a esto.


4/74

iv

Tabla de Contenido

1.

Introduccin .................................................................................................... 1

1.1.

Justificacin .......................................................................................................................... 2

1.2. Objetivos Generales ............................................................................................................. 3

2.

Antecedentes .................................................................................................. 4

2.1.

Definiciones .......................................................................................................................... 4

2.1.1. Rostering ....................................................................................................................... 4

2.1.2.

Indicadores del roster .................................................................................................... 5

2.1.3. Framework a utilizar ..................................................................................................... 6

2.1.4. Condiciones del proyecto ............................................................................................... 6

2.2. Sistema Actual ...................................................................................................................... 7

2.3.

Restricciones ......................................................................................................................... 8

2.4.

Software en el Mercado ..................................................................................................... 10

2.5.

Solver Existentes ................................................................................................................. 11

2.6. Modelo de Optimizacin Utilizado ..................................................................................... 11

3.

Concepcin de la Solucin .......................................................................... 13

3.1.

Principales Requerimientos de la Solucin ........................................................................ 13

3.2.

Diagrama de Flujo de la Solucin ....................................................................................... 14

3.3. Arquitectura del Sistema .................................................................................................... 16

3.4. Arquitectura Lgica ............................................................................................................ 17

3.5.

Diagrama de Despliegue ..................................................................................................... 18

3.6.

Modelo de Datos ................................................................................................................ 19

4.

Diseo Detallado de la Solucin ................................................................. 22

4.1. Diseo Detallado de Mdulos ............................................................................................ 22

4.1.1. MD001: Importar Datos .............................................................................................. 22

4.1.2. MD002: Edicin de Datos ............................................................................................ 22

4.1.3. MD003: Reportera ...................................................................................................... 23

4.1.4. MD004: Exportar Datos ............................................................................................... 24

4.1.5. MD005: Generar Rol .................................................................................................... 24

4.1.6. MD006: Editar Rol ....................................................................................................... 25

4.2.

Diseo Detallado de Navegacin ........................................................................................ 26

5.

Implementacin de la Solucin ................................................................... 29

5.1.

Configuracin Inicial ........................................................................................................... 29

5.2. Proceso de generacin de roster ........................................................................................ 29

6.

Evaluacin Preliminar de la Solucin ......................................................... 34

7.

Conclusiones y Trabajo a futuro ................................................................. 38


5/74

v

8.

Bibliografa y Referencias ............................................................................ 40

Anexos: ................................................................................................................ 41

A. Casos de Uso. ......................................................................................................................... 41

B.

Interfaces de Usuario ............................................................................................................. 45

C.

Diccionario de Datos .............................................................................................................. 53

D.

Diagrama Base de Datos ........................................................................................................ 63

E. Formato de los archivos de entrada de datos ....................................................................... 64

Informacin de lgica de negocios de Andes. ............................................................................ 64

Archivos de entrada de datos mensuales .................................................................................. 65


6/74

1

1. Introduccin

El problema de organizar los turnos es una de las dificultades que deben enfrentar todas

aquellas organizaciones que trabajan con personas en turnos rotativos. Junto con cumplir las

demandas de entrega de servicio, de calidad y prontitud, en el diseo de los turnos debe

tenerse en consideracin tambin las restricciones legales, sindicales, de capacidad de trabajo

de la organizacin as como tambin la calidad de la jornada laboral de los empleados. El trabajo

de generar estos turnos (o roles como se les conoce) es conocido como rostering1.

Andes Airport Services2es la mayor empresa encargada de las operaciones en tierra (Ground

Handling) del aeropuerto Arturo Merino Bentez de Santiago, representando aproximadamente

el 80% de las operaciones del terminal; adems, esta empresa est a cargo de las operaciones

en tierra de LAN Airlines en los aeropuertos de Guayaquil y Quito en Ecuador. Estas actividades

consideran el manejo de maletas, monitoreo de vuelos y el movimiento de pasajeros y aviones

en tierra. En una empresa de este tamao, con aproximadamente unos 800 empleados slo enel aeropuerto de Santiago, la generacin de turnos 24/7 es de suma importancia y criticidad.

Actualmente el proceso de rostering para los 800 empleados de Andes en el aeropuerto de

Santiago es realizado por una persona. Esta persona usa gran parte de su tiempo diario y del

mes en generar los turnos para cada uno de los cargos, realizando las asignaciones de manera

manual usando una planilla Excel. Luego, junto con el rea de manejo de personal comparan el

roster propuesto, contra la capacidad necesaria para llevar a cabo las operaciones diarias.

Finalmente se entregan los turnos a los empleados.

El objetivo de Andes para hacer esta labor ms eficiente consiste en investigar y desarrollaruna herramienta tecnolgica que les permita generar estos rosters de manera automtica,

optimizando sus recursos humanos. La complejidad de este problema radica en que su solucin

consiste en resolver un problema de programacin lineal entera. La Programacin Lineal es un

procedimiento de modelamiento matemtico, mediante el cual se busca el ptimo de una

funcin (llamada objetivo) dentro de un espacio acotado por un sistema de ecuaciones y

desigualdades (restricciones). En este caso, las variables de decisin deben tomas valores

enteros, lo que hace este problema mucho ms difcil de resolver.

Actualmente existe software, llamados comnmente solvers

3

, capaces de resolver estosproblemas de programacin matemtica en forma eficiente. Sin embargo, estos requieren

conocimientos avanzados de programacin y modelamiento matemtico, la entrada de datos

1Del Ingls: roster planilla

2http://www.andesairportservices.com/es/

3 Ejemplos de estos productos son: CPLEX, Gurobi, MOSEK, CBC (COIN-OR Branch and Cut), Microsoft Solver

Foundation.


7/74

2

utilizada es poco conveniente y sus resultados no son evidentes para aquellos que no tienen

conocimientos en su utilizacin, lo que los vuelve poco apropiados para una empresa. Es por

esto que se requiere un sistema capaz de interactuar tanto con el usuario final como con el

solver, manejando el flujo de datos y entregando herramientas para la edicin de roles y su

gestin.

Existen tambin, software comerciales diseados para la generacin de roles. Sin embargo,

por la cantidad de restricciones as como por los resultados esperados del modelo, es

fundamental y parte central de este proyecto de Rostering, la creacin de un sistema

computacional capaz de manejar tanto la informacin (data) que ingresa as como los resultados

finales.

1.1. Justificacin

El proceso completo de rostering para Andes toma aproximadamente 20 das, depende en

gran medida de las disponibilidades horarias de cada una de las personas involucradas, y no

admite ningn tipo de administracin o gestin de los roles generados. Adems esta solucin no

permite la obtencin de reportes peridicos de eficacia, de cantidad de das libres utilizados o

de sobre/baja utilizacin de la fuerza laboral disponible.

El sistema que se desarroll en esta memoria consiste en una interfaz de captura de datos a

la que se le ingresa informacin desde el rea de RRHH de Andes y los requerimientos de

personal activo cada hora, permitiendo su edicin y manejo para que, finalmente, sea generado

un roster mensual completo optimizando un problema de programacin lineal entera. Este

problema tiene como restricciones las capacitaciones del personal y normativas

legales/sindicales y busca optimizar la cantidad de horas trabajadas, el cumplimiento de dichasnormativas y una mejora en la calidad de vida del personal.

El sistema propuesto afecta a un grupo importante de personas, involucra a un equipo de

trabajo multidisciplinario, y aborda un problema real y concreto. El rea de la computacin ms

involucrada en este proyecto ser la ingeniera de software, pues ste es bsicamente un

proyecto de anlisis, diseo y construccin de software. El modelamiento y optimizacin de

procesos ser generado por especialistas, y ser considerado un mdulo cerrado para el

proceso de desarrollo del sistema. Tambin se deber trabajar con el personal de Andes para

lograr identificar todos los requerimientos y condiciones de aceptacin.

Se espera que el sistema provea tanto una mejora de la calidad de vida de los trabajadores,

as como tambin un aumento en la eficiencia de la reparticin de turnos de la empresa. En el

desarrollo y ejecucin del sistema, existieron varios desafos tcnicos y conceptuales

relacionados:

Investigar los problemas de programacin lineal-entera y su modelacin.


8/74

3

Comprender el uso de los solvers actuales.

Estudiar el desarrollo de interfaces para asegurar una buen usabilidad del software final.

Disear e implementar los mecanismos de interaccin entre un sistema orientado a

objetos y un solver de problemas lineales-enteros.

Buscar formas eficientes de procesar la informacin proporcionada.

Solucionar problemas de compatibilidad con bases de datos existentes

El manejo de un capital de trabajo humano representado por ayuda externa contratada

para la programacin.

Preparacin de documentos para cumplir con estndares LAN para proyectos de

software.

1.2. Objetivos Generales

Disear e implementar un sistema que permita manejar la informacin necesaria para elproceso de rostering de una empresa con turnos rotativos. Los objetivos especficos que se

desprenden del objetivo general son los siguientes:

Implementar herramientas que permitan la comunicacin entre las estructuras de datos

generadas y el modelo matemtico para la obtencin de resultados.

Disear e implementar estructuras para manejar la informacin necesaria para generar

el rostering.

Disear y generar interfaces de usuario que permitan realizar de manera cmoda las

tareas asociadas al proceso de rostering, tales como: edicin de datos, modificacin deturnos y asignaciones de capacitaciones y/o vacaciones.

Realizar pruebas de concepto en escenarios controlados, para validar el funcionamiento

del sistema desarrollado.


9/74

4

2. Antecedentes

Como preparacin a la creacin de arquitecturas e interfaces preliminares para un futuro

sistema, se inici un estudio del estado del arte de los procesos y aplicaciones para rostering, as

como tambin una investigacin del proceso actual de generacin de roles dentro de Andes y

del funcionamiento de solvers. Los resultados de dichas indagaciones se presentan acontinuacin.

2.1. Definiciones

Para entender de mejor manera el trabajo realizado es necesario entender, en primer lugar,

en qu consiste el rostering, las herramientas que se utilizaran y las condiciones en las que se

trabaj.

2.1.1. Rostering

El problema de calendarizar los turnos para un grupo de personas es conocido en la literatura

como Personnel Schedullingo Personnel Rostering, dependiendo del horizonte de planificacin

que se aplique. En el contexto de esta memoria, se utilizar el trmino rosteringpara referirse al

proceso de asignar a cada persona un esquema de turnos que debe cumplir durante un mes,

mientras que roster o rolse referir al resultado de dicho proceso.

Este problema, que a primera vista puede parecer simple, rpidamente gana complejidad en

la medida que aumenta la cantidad de personas a planificar y con ellas las combinaciones

posibles de soluciones. Otro factor que hace crecer la complejidad es la inclusin de

restricciones y/o obligaciones especficas que se deban cumplir, como por ejemplo cuando

existen habilidades especiales que pueden ser cubiertas por slo una fraccin del personal [1][2] [3].

El tema de rostering es un problema sumamente estudiado por el rea de gestin de

operaciones, pues corresponde a un importante tem al momento de buscar donde mejorar la

eficiencia de una empresa. En las soluciones actuales se utilizan tanto software especializado

como herramientas generales para manejar la generacin de roles. Un enfoque tpico para

resolver problemas de este tipo es el uso de modelos de optimizacin matemtica, que

corresponden a la representacin del problema a travs de relaciones matemticas, de acuerdo

a una funcin objetivo que dependen de un grupo de variables que deben determinarse y cuya

solucin corresponde a la configuracin ptima de turnos. Estos modelos en general son

conocidos como problemas de programacin matemtica, y debido a su complejidad son

resueltos por herramientas tecnolgicas llamadas solvers. Sin embargo, la solucin que entrega

un solver a la funcin objetivo es, por defecto, un nmero real y el resultado del modelo es la

configuracin ptima de turnos. Sin embargo, debido a la naturaleza del problema a resolver,

slo nos interesan configuraciones donde las variables toman valores enteros. Sin esta

restriccin, puede incluso ocurrir que se asignen fracciones de persona a fracciones de turnos, y


10/74

5

es por este motivo que el modelo que se busca resolver es en verdad un problema de

programacin lineal entera.

2.1.2. Indicadores del roster

Para identificar la calidad de una asignacin y si es o no aceptable, se utilizan una serie de

indicadores o KPI (Key Performance Indicators). Estos indicadores son detallados en las

siguientes tablas.

Indicadores por persona Descripcin

N de aperturas N Turnos de Apertura por persona

N de tardes N Turnos de Tarde por persona

N de noches N Turnos de Noche por persona

N de libres N de Das libres por persona

N de salientes N de Das Salientes por persona

N de Domingos N de domingos Libres por persona

N de Libres consecutivos. N de veces que la persona tiene al menos dos libres

consecutivos

Quiebres N de cambios de turnos sin anteponer Libre por persona

N de das libres por semana N de libres en cada semana

Equilibrio Desviacin respecto distribucin equilibrada de turnos

Apertura/Tardes/Noche.

Vacaciones N de Das de Vacaciones

Capacitaciones N de das con cursos o capacitaciones.

Indicadores por cargo Descripcin

Subdotacin N de personas por debajo del personal requerido

Sobredotacin N de personas por sobre el requerimiento de personal

Cobertura % del requerimiento total que se satisface

N Libres Promedio de das libres

Equilibrio Nmero de personas en el cargo con asignacin equilibrada.

Distribucin secuencias de

libres

Cantidad de personas que tiene 1,2,3,4 semanas con das

libres seguidos


11/74

6

Estadsticos por tipo de turno Mximo/mnimo y promedio para turnos tipo Apertura, Tarde

y Noche

2.1.3. Framework a utilizar

Para la realizacin del sistema se utiliz el Oracle Application Development Framework

(Oracle ADF) [4] [5] para facilitar el trabajo tanto con base de datos Oracle como con las pginas

dinmicas y tablas editables necesarias para los usuarios, esto pues este framework permite la

generacin de vistas y controladores para la obtencin de datos de manera rpida gracias al IDE

integrado de Oracle: JDeveloper.

Oracle ADF es un framework comercial basado en el lenguaje Java para la creacin de

aplicaciones empresariales. Basado principalmente en un enfoque visual y declarativo para la

construccin de las aplicaciones, utiliza el patrn MVC y soporta integracin con diversas

tecnologas, tales como EJB, Web Services, JavaBeans, ADF Business Component, JavaServer

Faces y Struts. Provee componentes integrados con AJAX para obtener una experiencia de uso

fluida y libre de refrescos en pgina. Est orientado a componentes y muy ligado a JavaServerFaces, permitiendo la generacin simple de pginas con consultas y filtros.

Se escogi este framework por una serie de razones. La ms importante de ellas corresponde

a que LAN, pese a no seguir ningn estndar respecto a frameworks externos, posee licencias

para servidores y bases de datos Oracle, adems de entregar Documentos con Estndares para

ellos. Esto permite que el grueso de la estructura a generar (JavaBeans, tablas y conectores) se

apegue a los requerimientos de LAN para los desarrolladores externos. Otra de las razones es

que gracias al enfoque declarativo del framework y su nfasis en el patrn MVC, los constantes

cambios que los clientes exigan tanto en manejo de datos como de interfaces se podan

generar de manera rpida y eficiente.

2.1.4. Condiciones del proyecto

Andes Airport Services corresponde a una empresa filial de LAN por lo que cualquier

herramienta tecnolgica que se desee implementar debe, en primer lugar, obedecer los

alineamientos y estndares que LAN requiere para sus proyectos de software. Sin embargo,

debido a la naturaleza de este producto, el cual engloba a una herramienta de investigacin y

desarrollo matemtico y modelacin, se decidi que la solucin a desarrollar obedecera al

trmino prueba de concepto al interior de LAN, una figura creada para comprobar la

factibilidad de un proyecto sin entrar al flujo normal de desarrollo. Este trmino se traduce enuna mayor libertad al momento de planear y desarrollar la aplicacin pues no se deben

presentar papeles o documentacin a LAN en ningn momento, teniendo la capacidad de

modificar objetivos y entregas, mientras se tiene el acceso a las mquinas y a las arquitecturas

de desarrollo al interior de LAN. Sin embargo, por no tratarse de un desarrollo que siga las vas

normales, el software no puede tener ningn tipo de conexin directa con los sistemas legados

en Andes, incluyendo sus bases de datos. Se debe aclarar, sin embargo, que la solucin aqu


12/74

7

presentada obedece a las convenciones existentes de LAN para sus proyectos de software y que

la documentacin, pese a no ser requerida, fue entregada satisfactoriamente.

2.2. Sistema Actual

Actualmente el proceso es realizado por un administrativo utilizando el software Microsoft

Office: Excel, quin demora hasta veinte das en realizar la planificacin de todo el personal. Elproceso se describe en la siguiente figura.

Figura 1: Proceso actual de Rostering

1.

El administrativo mantiene la informacin necesaria sobre el personal en sus sistemas

(planillas Excel) y la va actualizando en la medida que Recursos Humanos le enve nueva

informacin va correo electrnico respecto de:

a.

Dotacin Vigente.

b.

Capacitaciones, licencias mdicas y habilitaciones vigentes.

c.

Vacaciones programadas.d. Grupos de trabajo pre-formado.

2. Para cada cargo, un funcionario a la vez, se procede a hacer su planificacin mensual,

intentando asegurar que se cumpla:

a.

El requerimiento de personal (por hora) presupuestado para el mes.

b.

Normativas legales.

c. Acuerdos sindicales.


13/74

8

d. Requisitos de turnos especiales de algn operario.

El algoritmo que sigue el planificador para cada operario es el siguiente:

a. Fijar vacaciones y capacitaciones

b. Llenar para cada da de acuerdo a las preferencias de turnos especiales.

c. Modificar las asignaciones realizadas hasta alcanzar una solucin que cumpla

adecuadamente con el presupuesto y demanda de personal de cada turno.

3.

Mientras se est realizando la planificacin, llegan nuevos requerimientos desde RR.HH.

(va correo electrnico), los cuales implican revisar las asignaciones ya realizadas.

4. Una vez terminada la planificacin, el administrativo y el personal del rea de

Operaciones proceden a revisarla, tomando en consideracin los ajustes sobre la

demanda de personal en servicio. Este proceso suele modificar considerablemente el

roster planificado anteriormente.

5.

Finalmente se confeccionan las pautas diarias y se imprime el rol de cada funcionario.

Figura 2: Ejemplo de planilla del rol para un cargo. Cada fila corresponde a un operario, cada columna a un da.

2.3. Restricciones

El objetivo del proceso de rostering es cubrir a cabalidad la demanda de personal que serequiere en cada turno. Sin embargo, los roles que se deben generar deben estar sujetos a una

serie de restricciones. Estas condiciones, que son impuestas por distintas fuentes, tienen cierta

flexibilidad para ser cumplidas: algunas deben ser observadas a cabalidad mientas que otras

quedan a discrecin del planificador. Se detallan a continuacin estas restricciones, detallando

la flexibilidad asociada a cada una de ellas.


14/74

9

Cdigo del trabajo:

Las condiciones que impone el cdigo del trabajo al proceso de rostering deben ser

cumplidas, en su mayora, a cabalidad. La nica en la que existe cierta flexibilidad es la que hace

referencia a la cantidad mnima de domingos al mes (la norma corresponde a 2 domingos libres

al mes), pues debido a un acuerdo con el sindicato de trabajadores es posible solamente 1

domingo legal.Descripcin Flexibilidad

Cantidad de domingos libres por mes Media

Descanso mnimo entre turnos de trabajo Ninguna

Mximos das seguidos que se puede trabajar Ninguna

Mximo de horas extras diarias Ninguna

Distribucin de la jornada de trabajo Ninguna

Vacaciones legales Ninguna

Ausentismo Legal Ninguna

Fines de semana libres por mes Ninguna

Nmero de das que puede trabajar en una semana Ninguna

Nmero de das que puede descansar en una semana Ninguna

Mximo de horas de trabajo legales Ninguna

Segn contrato:

El cargo en el cual se asigna a un trabajador puede variar. Esto ocurre para los cargos que

comparten capacitaciones y aunque ocurre rara vez, es uno de los factores libres con los que

puede trabajar el planificador.

Descripcin Flexibilidad

Cargo al que pertenece el empleado Alta

Sindicales:

Las normas sindicales, al igual que las normas legales, son restricciones que deben sercumplidas a cabalidad.

Descripcin Flexibilidad

Libres asignados al Comit paritario Ninguna

Mxima cantidad de noches seguidas trabajables Ninguna


15/74

10

Turnos asignados despus de trabajar el mx. de noches Ninguna

Hora de ingreso despus de trabajar el mx. de noches Ninguna

Recursos Humanos:

Las restricciones impuestas por el rea de Recursos Humanos de la empresa son las

condiciones ms flexibles que se le imponen al proceso de rostering y algunos corresponden, almismo tiempo, a ciertos indicadores para identificar la calidad subjetiva de un roster.

Descripcin Nivel de accin Flexibilidad

Ausentismo programable Planificado especficamente por empleado Media

Preferencia por turnos y das Planificado especficamente por empleado Alta

2 libres continuos al mes Comn a todos los empleados Baja

Calidad de vida Comn a todos los empleados Media

2.4. Software en el Mercado

Existen 2 tipos de soluciones de software que buscan resolver el problema de rostering. Por

un lado existen las soluciones que slo buscan entregar herramientas para la asignacin de

turnos realizada por personas. En su mayora, stos ofrecen una interfaz que permite visualizar

las posibles asignaciones, y entregan la capacidad al usuario de utilizarlas para su personal. Estas

soluciones son efectivas para problemas simples, como asignacin de turnos de garzones o de

guardias. El segundo tipo de soluciones corresponden a aquellas que buscan generar por medios

propios y sin la interaccin directa con un usuario, la asignacin para la planilla de empleados.

Es este tipo de aproximacin lo que se busca en este trabajo.

El problema de rostering para el personal de aeropuerto, ha sido estudiado

mayoritariamente para cargos especficos y, en pocos casos, para un conjunto grande de cargos;

los enfoques ms usuales para resolver los problemas de rostering son la programacin entera,

la programacin por restricciones y heursticas especficas que son realizados, en algunos casos

por consultoras externas o reas especficas de las empresas utilizando software a medida.

Muchas de las actuales soluciones de software para manejo de personal en turnos rotativos se

venden en el formato de Suite. Algunas de las empresas que entregan estos servicios y sus

respectivos productos son: Sabre, Sabre AirCentre, Navitaire, Planning Optimization Suite oJeppesen, Jeppesen Crew Rostering. Sin embargo, la informacin acerca de sus capacidades e

interfaces no es de dominio pblico, por lo que no se pudo llevar a cabo una investigacin

detallada de ellos.

Debido a la condicin de prueba de conceptodel proyecto, se decidi utilizar un sistema a

medida, un modelo de optimizacin especifico y un solver capaz de solucionarlo. Esto con el fin


16/74

11

de evitar los altos costos de las soluciones actuales y para generar una solucin que se adaptara

perfectamente a las necesidades especficas de Andes, tanto de plataformas y sistemas legados

como de restricciones para el modelo. As se evitan tambin, los costos de capacitacin y

mantencin, quedando estos a cargo de LAN una vez que el proyecto termine.

2.5. Solver Existentes

Un solver es un software escrito en un lenguaje de programacin (por ejemplo, C, C++, Java o

incluso Python) que toma un problema matemtico modelado en un lenguaje particular, como

por ejemplo: AIMMS (Advanced Interactive Multidimensional Modeling System), OPL

(Optimization Programming Language), GAMS (General Algebraic Modeling System) o AMPL (A

Mathematical Programming Language), y lo resuelve.

Dentro de los posibles solvers a utilizar se estudiaron una serie de ellos, en sus versiones

acadmicas que sern detallados a continuacin:

IBM ILOG CPlex. Desarrollado por IBM es una opcin pagada desarrollada originalmente

en C. Actualmente tiene libreras e interfaces que permiten su uso desde C++, C# eincluso Python. Su licencia comercial se eleva a los US$20.000 por unidad.

COIN-OR: CBC. Desarrollado por el proyecto COIN-OR (Computational Infrastructure for

Operations Research) es una solucin de cdigo libre y, en su mayor parte, consta de

libreras y plug-ins desarrollados para C++.

Gurubi:Desarrollado por el mismo equipo que elabor CPlex, es una opcin pagada. Sus

libreras y plug-ins estn desarrollados en su mayor parte en el lenguaje Java aunque

tiene interfaces y libreras para C++ y C#. Es, de entre todos los presentes, el que tiene

mejor resultados en benchmarking [6]. Su licencia comercial se eleva a US$12.000.Para estudiar la factibilidad tcnica y la calidad de las soluciones se realizaron pruebas

utilizando COIN-CBC, estos son los resultados que se entregan en la presente memoria. Se

seleccion este solver por ser una solucin de cdigo libre, que nos permita entregar soluciones

a una empresa privada y cuyos tiempos de resolucin eran satisfactorios.

Para la implementacin final en los servidores de LAN, sin embargo, se utiliz Gurubi, debido

a su bajo precio, mejores tiempos de resolucin y conocimientos de su uso por parte del equipo

desarrollador.

2.6. Modelo de Optimizacin Utilizado

El modelo de optimizacin, como ya fue comentado, queda fuera de los alcances de esta

memoria. Sin embargo, al corresponder a una parte fundamental del sistema a construir es

necesario explicar su comportamiento esperado y los lmites de su utilidad.

El modelo de optimizacin cumple el deber de generar, a partir de informacin recopilada,

una planificacin mensual de turnos para cada empleado por cargo. Esto se logra optimizando


17/74

12

su funcin objetivo y respetando las restricciones que acotan el problema a solucionar. La

informacin ingresada deben estar en formatos preestablecidos y tanto la funcin objetivo

como sus restricciones se encuentran escritas en un lenguaje propio de programacin

matemtica. Es importante notar que debido a la complejidad inherente del modelo propuesto,

se decidi acotar las instancias a un nico cargo a la vez.

La funcin objetivo del modelo busca encontrar la mejor cobertura posible para las

necesidades de la operacin. Esto se logra minimizando la subdotacin y la sobredotacin de

personal para cada turno, respetando todas las restricciones detalladas en la seccin 2.3:

Restricciones.Este enfoque mostr en las pruebas los mejores resultados, tanto en el tiempo

necesario para encontrar una solucin aceptable, como de cantidad de cambios necesarios para

su implementacin.

La informacin necesaria para que el solver resuelva el modelo corresponde a: los

requerimientos de personal para cada turno, las vacaciones, las capacitaciones, las habilidades

individuales de cada empleado, as como tambin turnos prohibidos o turnos pedidos para cadaempleado. Esta informacin, que es ingresada por medio de archivos de texto, obedece a

formatos predefinidos y no son de fcil lectura para usuario promedio.

El resultado que se obtiene finalmente, a partir de los datos ingresados, corresponde a una

configuracin de turnos para cada empleado en un cargo particular. Esta configuracin, sin

embargo, no es necesariamente la ptima. En efecto, debido a la complejidad del modelo, el

tiempo necesario para encontrar la solucin ptima puede resultar demasiado largo,

considerando las necesidades de la operacin, por lo que se debe acotar el tiempo destinado a

encontrar el ptimo. Es entonces posible que dentro de la ventana de tiempo asignada, no se

alcance la configuracin ptima y por lo tanto, la solucin obtenida deba ser editaba. Sin

embargo, y como podr ser visto en el captulo6, los resultados que se obtienen del modelo

matemtico cumplen de mejor manera y en menos tiempo las necesidades requeridas por la

empresa.


18/74

13

3. Concepcin de la Solucin

Para una planificacin correcta fue necesario un levantamiento completo de las necesidades

existentes en la empresa para la identificacin apropiada de los requerimientos de usuario y

software para su posterior diseo e implementacin. De la misma manera, fue necesario el

mismo proceso para los datos necesarios que utilizara el modelo y para la forma de entregar losdatos desde Andes al sistema de software finalizado. A continuacin se presentan los resultados

obtenidos de todo el proceso de identificacin de requerimientos para la solucin de software.

3.1. Principales Requerimientos de la Solucin

Los siguientes requerimientos se recabaron luego de mltiples reuniones con el cliente y

hacen referencia tanto a requerimientos propios de la solucin de software como a necesidades

referentes a la construccin del modelo matemtico. Ambos tipos fueron estudiados y

compilados al mismo momento, pues ambos deberan encontrarse en la solucin final: las

funcionalidades requeridas en el sistema de software y la capacidad del sistema paraproporcionar el ambiente necesario para que el modelo realice clculo y entregue los resultados

requeridos.

Id Requerimientos de

usuario

Descripcin Prioridad

1 Generacin de roles

mensual

Generar un rol para cada operario, segn cargo, considerando los

requerimientos de cada turno y las restricciones legales y sindicales. El rol

debe ser posible de generar de forma independiente por cada cargo o de

forma agregada para algunos operarios simultneamente. Debe considerar

los resultados de meses anteriores.

Alta

2 Roles editables Cargar un rol ya generado y realizar cambios en forma manual. El sistema

debe evaluar la calidad del rol.

Alta

3 Incorporar Indicadores de

calidad de Vida

Utilizar los indicadores de calidad de vida (equilibrio de turnos en las

asignaciones, libres al mes) como uno de los objetivos a considerar en el

momento de generar roles.

Media

4 Evaluar la calidad de rol Tener una forma "sencilla" de medir la calidad de un rol, que considere (al

menos): cobertura de la operacin, uso de horas extras, uso eficiente de

recursos (HH), calidad de vida.

Alta

5 Parametrizacin de

inputs

Asignarles peso/importancia a indicadores por definir al momento de

generar roles.

Media

6 Gestionar roles

generados

Poder monitorear el desempeo de los roles a lo largo del mes. Que pueda

modificar las asignaciones futuras para responder a imprevistos,

modificando el rol general lo menos posible.

Alta

7 Interfaz para la operacin La interfaz para generar y modificar roles debe cumplir con los estndares de

usabilidad para alguien con conocimientos computacionales a nivel usuario.

Alta


19/74

14

8 Generar archivo de salida Se generar un archivo de salida, que indica en cada cargo los operarios que

cumplirn cada labor, horas de ingresos y salidas.

Baja

9 Reportes parametrizables Las soluciones deben quedar guardadas de forma que permita la

parametrizacin de nuevas consultas para generar reportes, y que ests

queden guardadas.

Media

10 Estudiar rosters pasados

o futuros

Se debe permitir poder estudiar un mes pasado o futuro, generando el

roster a partir de cambios particulares (modificar la dotacin de personal, los

requerimientos, las habilidades, esquemas de operacin, cumplimiento de

los indicadores).

Alta

11 Extraccin de

informacin de bases de

datos.

El sistema debe ser capaz de obtener la informacin necesaria para

gestionar y generar un rol a partir de una base de datos no necesariamente

conectada al sistema.

Alta

Utilizando estos datos, se detallaron los casos de uso esperados, que han sido adjuntados en

el Anexo A: Casos de Uso.

3.2. Diagrama de Flujo de la Solucin

A partir de los requerimientos antes descritos y de las reuniones realizadas con el equipo de

Andes, se extrae el siguiente flujo de procesos para el caso de uso principal, el cual se

representa grficamente en la figura 3. A continuacin se describen tambin las principales

actividades de este proceso.

Figura 3: Proceso Rostering de Andes (BPMN)

1.

Al momento de iniciar la generacin de roles, se ingresan los datos al sistema. Estos

datos consisten en la informacin de dotacin, grupos de habilidades, cargos, licencias,

etc. (ver figura 4) y son ingresados al sistema mediante la importacin de archivos. La

informacin as ingresada debe ser revisada y puede ser modificada por el usuario. El


20/74

15

proceso puede continuar slo si el usuario se encuentra satisfecho con la informacin

entregada al sistema.

Figura 4: Detalle de los distintos datos que necesita el sistema

2.

Con los datos correctamente ingresados en el sistema, comienza el proceso degeneracin de rol. Este comienza con la seleccin del cargo sobre el cual se ejecutar el

solver y el tiempo posterior de espera para que se encuentre una solucin. Una vez

generado el archivo de salida para el software, se extrae la informacin para un rol y se

calculan los diversos indicadores que Andes requerir para medir la calidad del rol.

Figura 5: Detalle del proceso de optimizacin de rol

3. Si el usuario, al revisar los indicadores e inspeccionar el rol lo considera adecuado,

entonces se termina el proceso y es impreso y entregado a los operarios. En caso

contrario, modifica manualmente el rol para casos en que las diferencias sean mnimas opasa a editar los datos de entrada al solver, en cuyo caso el software es nuevamente

llamado con nuevos datos.

4. Uno de los requerimientos con alta importancia para Andes corresponde a la capacidad

de revisar y volver a generar, con datos diferentes, roles para meses pasados o futuros.

En este caso, el flujo sera similar al principal.


21/74

16

Con estos requerimientos e informacin, se conceptualiz una solucin capaz de resolver las

necesidades de Andes recin expuestas. Esta solucin es la que representa en el siguiente

esquema (figura 6), donde cada objeto representa una funcionalidad requerida o la necesidad

de una estructura.

Figura 6: Esquema de la solucin

3.3. Arquitectura del Sistema

En una primera instancia se plane trabajar con una arquitectura cliente-servidor, con un

cliente que contuviera parte de la lgica del sistema y un servidor que manejara las consultas y

contuviera el solver de optimizacin. Sin embargo, esta aproximacin tiene el problema de

hacer difcil la mantencin. Es por esto que en un segundo enfoque se decidi por una

aplicacin web y una arquitectura de sistema de n-capas. Este tipo de arquitecturas tiene la

ventaja de entregar modularidad al sistema y permitir una mantencin mucho ms simple.

Finalmente, se lleg a una arquitectura del sistema como se muestra a continuacin.


22/74

17

Figura 7: Arquitectura fsica de 4-capas

Capa Cliente: La capa de cliente es la encargada de entregar la interfaz con la que el usuario

estar en contacto con el resto del sistema.

Capa Presentacin: Se tom la decisin de trabajar con un contenedor web cuyas licencias ya

existan al interior de LAN, por lo que esta capa corresponde a un servidor WebLogic.

Capa Lgica: Esta capa consta de 2 funcionalidades claramente definidas:

El Sistema de Gestin de Roles corresponde al grueso del sistema, y es el encargado de

manejar la informacin que entra y sale de la capa de recursos. ste se encarga tambin

de formatear la informacin de la base de datos, y pasarla a archivos para que sean

ledos por el solver y de transformar la salida datos.

El solver es un software que toma datos desde archivos y utilizando metodologas de

resolucin de problemas de programacin lineal-entera, entrega resultados que cumplen

con restricciones previamente definidas. Estos resultados sern entregados como

archivos de texto que tendrn que ser parseados por el Sistema de Gestin antes de ser

entregados al usuario.

Capa de Recursos: Esta capa consiste en una base de datos con informacin detallada del

personal en la que se mantiene la informacin persistente del sistema, como datos histricos

y de restricciones del modelo (estructura de leyes laborales y de manejo de turnos, normas

sindicales, etc.). Debido a las necesidades de mantener la informacin para cada mes, es

necesaria la temporalizacin de la mayora de las tablas.

3.4. Arquitectura Lgica

A continuacin se presenta una vista de la estructura lgica del sistema:


23/74

18

Figura 8: Arquitectura Lgica

Un usuario cualquiera que quiera interactuar con el sistema debe hacerlo a travs de las

vistas que existirn para manejar sus consultas, que pueden ir desde la generacin de un roster,

a la edicin del mismo y de todos los datos que se necesitan para su generacin.

3.5. Diagrama de Despliegue

El diagrama mostrado en la figura 9 corresponde a la configuracin fsica sobre las que se

pondr en produccin el sistema. Por un lado, estn los sistemas existentes de Andes queincluyen sus bases de datos legadas y el browser con el cual el usuario entrar al sistema. Por

otro lado, se contemplan los 2 servidores entregados por el rea de TI de LAN, en los que se

encontrar el sistema: elservidor para aplicaciones weby el servidor de bases de datos.


24/74

19

Figura 9: Diagrama de Despliegue

3.6. Modelo de Datos

El modelo de datos se formul pensando en los 3 aspectos fundamentales que debe cumplirel sistema. Por un lado debe contener toda la informacin utilizada en el proceso de rostering

(requerimientos de personal e informacin de R.R.H.H.); debe adems entregar una interfaz que

provea las herramientas para la carga y edicin de esos datos. Finalmente, muchos de los datos

que son necesarios para la generacin de un rol son dependientes del mes, lo que significa que

para poseer la capacidad de editarlos y explorar posibles soluciones, el modelo debe tener algn

mecanismo o lgica que permita mantener varias versiones de la informacin para un mismo

mes.

Es por lo anterior que se pueden reconocer 3 agrupaciones de tablas dentro de la estructura

de datos: Los datos correspondientes a la lgica de negocio de Andes, los cuales en caso decambiar deben reproducirse a travs del tiempo; la informacin de R.R.H.H del personal, la cual

vara mes a mes; y la informacin de los requerimientos de personal los cuales tambin son

mutables. Para ver el detalle de las tablas, referirse al diccionario de datos ubicado en el Anexo

C: Diccionario de Datos.


25/74

20

Los siguientes diagramas muestran las tablas y las relaciones existentes entre ellas para las 3

agrupaciones de tablas que se comentaron anteriormente dentro de la estructura general: los

requerimientos de personal, la informacin de la empresay la informacin de los empleados.

Figura 10: Detalle Base de Datos: Informacin de los requerimientos de personal

Estas 3 tablas contienen la informacin acerca de la cantidad de personal que se necesita en

cada turno u hora dentro del mes y de las necesidades especficas por algn tipo de

capacitacin en particular. Estas tablas no tienen relacin directa entre s, aunque s se

relacionan con las tablas que contienen los permanentes de estructura de negocios de Andes:

en el caso de las tablas Capacity_Hora y Capacity_Turno, corresponde a la tabla Cargos de la

empresa, mientras que en el caso de Demanda_Skillcorresponde a Skills.

Figura 11: Detalle Base de Datos: Informacin del personal

La Figura 11 representa la seccin de la base de datos que contiene el mayor nmero de

relaciones de todas las secciones, mantiene la informacin respecto a cada empleado y la

empalma con su rol mensual. Esta informacin es de vital importancia que sea identificada por


26/74

21

el periodo en el que es vlida, as como su nmero de versin, pues sta vara mes a mes, y los

datos pueden ser modificados tanto para el mismo mes en curso, como para experimentos en

distintos escenarios futuros.

Figura 12: Detalle Base de datos: Informacin de Andes

Esta seccin de las tablas de la Base de Datos contiene informacin referente a temas

histricos de Andes. Regmenes de trabajo, definiciones turnos y cargos, grupos creados e

identificadores de skills. Esta informacin es referenciada por las otras tablas y su contenido no

admite versionamiento. Lo contenido en estas tablas refleja el modelo de negocio y las

definiciones de largo plazo de la empresa por lo que su edicin est restringida.


27/74

22

4. Diseo Detallado de la Solucin

En el captulo anterior se present la arquitectura general del software implementado. En

este captulo se analizar en primer lugar de forma detallada los mdulos a programar y cmo

se relacionan con las estructuras de datos ideadas. A continuacin se describir el flujo

proyectado a travs del sitio.

4.1. Diseo Detallado de Mdulos

A continuacin se presentan los mdulos que forman parte de la arquitectura lgica

presentada en la Figura 8, detallando la funcin que deben cumplir y los procesos que los

constituyen.

4.1.1. MD001: Importar Datos

Funcin: Permite agregar la informacin necesaria al sistema a partir de archivos extrados

de las distintas fuentes de datos (figura 13).

1.1

Seleccin de archivos o fuentes: El usuario escoge qu archivos desea cargar en el

sistema.

1.2Validacin de los archivos: Al seleccionarlos e intentar subirlos, se realiza una validacin

para confirmar que el(los) archivo(s) cumplen con el formato requerido.

1.3Subida de archivos al sistema: Habiendo sido validados, los archivos pasan a ser

cargados a la base de datos.

Figura 13: Importar Datos

4.1.2. MD002: Edicin de Datos

Funcin: Permite al usuario editar y agregar datos en la base de datos.

2.1Captura de consulta: Se capturan las consultas sobra las tablas que el usuario desea

revisar.


28/74

23

2.2Construccin de consultas: Se construyen las consultas capaces de realizar las

necesidades del usuario. stas incluyen inserciones, eliminaciones y actualizaciones a

los datos contenidos en la base de datos, con datos entregados en el momento por el

usuario.

2.3Formato de la respuesta: La informacin antes de ser entregada al usuario se procesa

para mantenerla en un formato usable por el usuario.2.4Edicin de Celdas: El usuario edita las celdas de las tablas mostradas en la vista de

edicin. Las modificaciones deben ser entregadas al mdulo 2.2 para que se generen

cambios en tiempo real en la base de datos.

Figura 14: Edicin de Datos

4.1.3. MD003: ReporteraFuncin: Diagrama y formatea la informacin de manera que el usuario pueda obtener

indicadores claves para el manejo del negocio de manera entendible a partir de la

informacin contenida en el rol.

3.1Captura del requerimiento de reporte: El usuario realiza la seleccin de qu reporte

desea generar y se captura ese requerimiento.

3.2Construccin del reporte: Se realizan las consultas a la(s) tabla(s) para obtener los datos

bsicos y se calculan los indicadores requeridos.

3.3Visualizacin de los KPI: Se cargan los datos e indicadores calculados y se diagraman en

la manera que es necesario para el reporte.


29/74

24

Figura 15: Reportera

4.1.4. MD004: Exportar Datos

Funcin: Entrega la capacidad de extraer los datos brutos desde el sistema y poder

observarlos en los sistemas legados existentes en Andes.

4.1Capturar Archivos a exportar: El usuario realiza previamente la seleccin de que

archivos particulares desea obtener.

4.2Obtener Datos: Mdulo encargado de generar las consultas necesarias para la

generacin de los archivos.

4.3Generar Archivos: A partir de los datos obtenidos por el MD004.2 se pasa a generar los

archivos en el formato y extensin requeridos.

Figura 16: Exporta Datos

4.1.5. MD005: Generar Rol

Funcin: Funcionalidad principal del sistema, a partir de los datos que se encuentran en la

base de datos y utilizando la exportacin de datos se le entrega la informacin del mes al

software solver para obtener un roster ptimo. Una vez que se tiene el resultado, este es

importando a la base de datos, donde puede ser editado, exportado y se le puede calcular

sus indicadores.


30/74

25

5.1Captura de cargos a generar: Captura los cargos a los que el usuario desea generar

roles.

5.2Validar informacin existente: Habiendo recibido los cargos, se consulta si existen datos

suficientes en la base de datos para generarlos.

5.3Exportar archivos: Confirmado que existen los datos mnimos necesarios, se procede a

generar los archivos que necesita el modelo en el formato que los necesita.5.4Comunicacin con el solver: Teniendo los archivos generados, se procede a llamar al

solver de modelos, dndole como parmetros el modelo de optimizacin y los datos

tomados desde la base de datos. Este mdulo adems debe quedar a la espera de los

resultados y manejar posibles timeouts.

5.5Ingreso de archivos al sistema: El solver entrega como respuesta un archivo, que debe

ser ledo y cargado al sistema antes de poder continuar.

5.6Despliegue del Rol: Por medio de consultas a la base de datos y habiendo obtenido

respuesta positiva del MD005.4 se procede a generar la vista de visualizacin de rol.

Figura 17: Generar Rol

4.1.6. MD006: Editar Rol

Funcin: El usuario debe tener la capacidad de generar modificaciones a un rol previamente

generado y que exista en el sistema. Estas modificaciones puede ser: cambios en los turnos,

agregar o quitar empleados, crear vacaciones y capacitaciones, etc. Estas modificaciones no

deben ser replicadas en la base de datos, tanto porque en algunos casos corresponden sloa pruebas de concepto de nuevos patrones de rol, como porque no es parte de las

atribuciones del rea de Planning.

6.1Captura de cambios: Se capturan los cambios que se desean realizar. Sean estos nuevos

datos o modificaciones a campos existentes.

6.2Validacin de cambios: Mdulo que valida que los cambios son realizables.

6.3Modificaciones en la base de datos: Mdulo que ejecuta los cambios en la base de datos


31/74

26

6.4Presentacin de los cambios: Mdulo que presenta los cambios al usuario.

Figura 18: Edicin de rol

4.2. Diseo Detallado de Navegacin

Junto con la descripcin detallada a nivel de mdulos de programacin que se identificaron y

se requieren para el funcionamiento del sistema completo, se debe describir tambin, el flujo

de pginas en las que estas funcionalidades sern utilizables por el usuario final y como ellas se

relacionan. Este flujo se muestra a continuacin:


32/74

27

Figura 19: Diseo detallado de Navegacin

Uno de las necesidades de Andes es que el proceso sea secuencial; esto es, que no se pueda

avanzar hasta que el paso anterior est confirmado. De esta manera, el flujo se vuelve

restrictivo en cuanto a la secuencia que se debe seguir y a los pasos finales del proceso quedan

sujetos a que se hayan realizado los pasos intermedios al menos una vez con anterioridad para

la instancia/mes que se est ejecutando.

1. Login: La primera vista a la que entra un usuario es la de identificacin. Uno de los

requerimientos de Andes de diferenciacin de usuarios y seguridad hacen necesario que

aquellos que desean utilizar el sistema deben tener estar certificados.

2. Men Inicial:La vista que se abre una vez ingresado el usuario es la de men inicial. En

sta se seleccionar el mes en el que se desea trabajar. A este nivel tiene que haber

visibilidad acerca de que actividades se pueden realizar: Si el mes ya tiene datos cargados

o un roster generado, se debe poder ir a trabajar directamente sobre ellos, saltndose los

pasos de carga y edicin de datos.

3. Cargar Datos: Por necesidades del ambiente en produccin del cliente, la informacin

necesaria para la construccin de un roster debe ser subida mes a mes y cargada desde

sus propias bases de datos como archivos de texto. Esto producto de que los servidores


33/74

28

donde finalmente estar desplegada la aplicacin web no tienen conexin con las bases

de datos internas que manejan al interior de la empresa y, al mismo tiempo, el

mantenimiento de las bases de datos proyectadas para cumplir con las exigencias de

temporalidad que requiere Andes hacen poco recomendable la copia de informacin ya

contenida en las tablas para nuevos meses.

4.

Edicin de Datos: Una vez que existan datos para el mes en que se trabaja, se puedeproceder a modificarlos. Para evitar anomalas en la base datos, en la vista de edicin de

datos, un usuario slo se podr editar datos mensuales de la informacin. Los datos

existentes que hagan referencia a informacin interna de Andes slo podrn ser

modificados por un administrador del sistema.

5. Seleccin de Cargos:Una vez que el usuario se encuentre satisfecho con la informacin

que existe en el sistema para el mes en cuestin, se puede proceder a seleccionar el o los

cargo(s) que se desea generar. Es en esta vista que se revisa si existen la cantidad mnima

de datos requeridas para la generacin de un roster.

6. Generacin de Roster:Esta detencin en el proceso de generacin de roster es la pgina

de espera a que el solver resuelva el modelo matemtico. Al interior del sistema, al

desplegarse esta pantalla, se estn exportando los datos de la base de datos al modelo,

corriendo el script de solver y quedando a la espera de un resultado o timeout.

7. Resultados del modelo: El resultado final del modelo matemtico corresponde a un roster

para los cargos que fueron seleccionados con anterioridad. Este resultado debe ser

editable. Cuando el usuario est satisfecho con el roster generado o modificado y el

trabajo realizado corresponde al roster del mes siguiente, este puede ser enviado a los

empleados de la empresa desde donde pasan a ser sus turnos para el mes.

Las interfaces que se generaron para cumplir con el flujo presentado se encuentran

detalladas en el Anexo B: Interfaces de Usuario.


34/74

29

5. Implementacin de la Solucin

En la siguiente seccin se presentan los pasos previos que se deben tomar para configurar de

manera correcta el sistema y una breve descripcin de las vistas y funciones implementadas.

5.1. Configuracin Inicial

Como primer paso se deben cargar al sistema las tablas que estn diseadas para contener la

informacin organizacional de Andes: Cargos, Turnos, Regmenes de trabajo y lista de Skills.

Para ingresar estos datos se agreg a la vista de administrador en la Cargar Datos la opcin de

incluir estos archivos. Los archivos a subir mantienen un formato estndar que se encuentra

detallado en el Anexo E:Informacin de lgica de negocios de Andes.

5.2. Proceso de generacin de roster

El proceso de generacin de un roster, descrito en la seccin anterior, se lleva a cabo a travs

de diversas vistas, funciones y revisiones que se producen dentro del sitio. Los pasos necesariosy los distintos requerimientos de cada uno son detallados a continuacin.

Si no existe un roster para una instancia de mes en particular, el flujo dentro del sitio es

lineal: se debe avanzar en cada paso y slo se podr avanzar al siguiente o retroceder al paso

inmediatamente anterior. Este flujo fue decidido por el cliente para mantener la lgica actual

del proceso de rostering. Sin embargo, si existe algn roster cargado para ese mes, ste es

visible y se puede pasar directamente a su revisin.

1. Login: Se hace una revisin de certificaciones del usuario al momento de ingresar para

manejar los permisos de edicin sobre informacin crtica.

Figura 20: Interfaz de Login

2. Men Inicial:Una vez ingresado en el sitio, se puede seleccionar el mes en el que se desea

trabajar. Al seleccionarlo se carga el detalle de la informacin existente para aquel mes:

archivos subidos y cargos con roles creados.


35/74

30

Figura 21: Men inicial

Una vez que se selecciona el mes, este se mantiene disponible para el resto de las vistas.

Este punto es relevante pues las funcionalidades del sistema toman en consideracin la

fecha en la que se est trabajando en el sistema, se puede pasar al resto del sitio. Si no

existen roles generados para ese mes se continua con la secuencia aqu detallada, en caso

contrario, se puede pasar a cualquiera de los pasos posteriores.

3. Cargar Datos:Para poder generar un roster, se requiere de una cantidad definida de datos

que corresponden a la informacin de requerimientos y restricciones varias. Estos datos son

ingresados al sistema por medio de esta pgina, separados por archivos de entrada de

extensin CSV y que respetan un formato previamente establecido e informado, detallado

en el AnexoE: Formato de los archivos de entrada de datos


36/74

31

Figura 22: Carga de datos

Al momento de subir archivos se comprueba que los datos ingresados se adhieran al

formato establecido y que los datos correspondan a la informacin que debe ser ingresada

por medio de ese archivo. Sin embargo, no es posible hacer una comprobacin exhaustiva

de la lgica detrs de los datos ingresados: esta debe haber sido correctamente ingresada alos sistemas de Andes.

4. Edicin de Datos:Esta vista, que permite la edicin de los datos contenidos consiste en una

lista desplegable con todos los datos disponibles a modificar para el usuario. Una vez que se

selecciona un elemento, se despliega toda la informacin de esa tabla.

Figura 23: Seleccin de tabla a editar


37/74

32

Figura 24: Edicin de tabla

Una vez que la informacin se despliega en pantalla, se aprecian 2 secciones. La primera,contiene una tabla con toda la informacin contenida en el sistema para el mes del sistema

y otra que permite la edicin de los campos. La tabla puede ser ordenada segn cualquiera

de sus columnas, y se puede filtrar casos particulares utilizando fragmentos o secciones

completas de informacin. Una vez que el usuario est satisfecho con los datos contenidos,

se puede continuar al siguiente paso.

5. Seleccin de Cargos:Se revisa qu datos cargados existen en el sistema, y de existir cundo

fue la ltima generacin de rol. Slo se puede pasar a la siguiente vista con aquellos cargos

con los que se cuenta la informacin necesaria para que el solver pueda obtener un

resultado.


38/74

33

Figura 25: Seleccin y revisin de datos

6.

Edicin de roster: Una vez que se obtiene un roster desde el solver, se puede revisar en la

vista de edicin. Esta consiste de una seccin donde se puede apreciar toda la informacin

del roster, con la capacidad de filtrar tanto por cargo, como por datos de empleado. Al

seleccionar una fila, se despliega toda la informacin de esa persona en una segunda zona,

en la que se puede editar los turnos asignados al empleado.

Figura 26: Edicin y revisin de roster


39/74

34

6. Evaluacin Preliminar de la Solucin

El objetivo de la presenta solucin constaba en la reduccin del tiempo del proceso de

rostering. Este proceso, como ha sido explicado, consta de 3 fases: La captura de datos, la

asignacin de turnos y la edicin de la solucin.

En primer lugar, se debe comprobar que el sistema produce roles con la misma o mejor

calidad que el proceso manual. Para esto se pueden revisar los resultados y evaluarlos segn los

indicadores con los que la empresa trabajaba. El de mayor importancia corresponde a la

medicin de cobertura para los turnos. Este registro es calculado de manera sencilla

comparando la cantidad de personal planificado para cada turno/hora contra la cantidad

requerida de personal. Si este indicador lo tomamos a nivel de cargo y luego lo ponderamos por

la cantidad de personal que trabaja en dicho cargo obtenemos otro indicador relevante, el

porcentaje cubierto de turnos.

A continuacin se puede revisar una comparacin entre un roster generado utilizando elnuevo sistema de planificacin de personal y sistema manual anterior. Se comparan los niveles

porcentuales de cobertura por cargo, la capacidad para cumplir con las obligaciones sindicales o

de preferencia de turnos del personal y la ponderacin cobertura/personal.

Tabla 1: Comparacin del porcentaje de cobertura

Apertura Tarde Noches

Cargo Dotacin Andes U. Chile Andes U. Chile Andes U. Chile

Cargoloaderista 21 97% 87% 60% 87% 100% 100%

Conductor Carrusel 8 100% 88% 77% 90% 100% 100%

Coordinador Equipaje 20 100% 99% 100% 100% 100% 100%

Jefe Turno Rampa 9 100% 100% 100% 100% 100% 100%

Monitor de Vuelo 55 89% 85% 85% 86% 88% 100%

Monitor Opco 21 98% 85% 75% 75% 73% 100%

Operario Equipaje 135 100% 100% 100% 100% 100% 100%

Towing 24 80% 83% 80% 100% 100% 100%

Tractorista PEQ 34 100% 98% 100% 100% 100% 100%

Operario Rampa 145 86% 90% 96% 90% 68% 85%

Ponderacin de Cobertura 93% 93% 93% 93% 88% 95%

Tabla 2: Comparacin de obligaciones cumplidas

Restricciones cumplidas

Cargo Andes U. Chile Dif.

Cargoloaderista 191 231 +18%

Conductor Carrusel 69 126 +45%

Coordinador Equipaje 324 324 0%

Jefe Turno Rampa 224 271 +18%


40/74

35

Monitor de Vuelo 384 465 +18%

Monitor Opco 0 286 +100%

Operario Equipaje 704 747 +6%

Towing 264 300 +12%

Tractorista PEQ 791 791 +0%

Operario Rampa 302 311 +3%

Se puede observar que la cantidad de requerimientos que se cumplen es mayor utilizando el

nuevo sistema y la ponderacin de coberturas se mantiene estable tanto para los turnos de

maana y tarde mientras mejora en el caso de los turnos nocturnos. Esto corresponde a un

proceder deseable pues los turnos de noche son, en la prctica, los que acumulan mayor

cantidad de licencias mdicas e inasistencias por lo que a nivel de planificacin se deben

mantener completamente dotados. Se debe notar tambin, que los cargos en los que se ve

menor cobertura para ciertos turnos, en general, son tambin los cargos en que existen las

mayores diferencias en restricciones cumplidas entre el antiguo sistema y el nuevo.

El segundo de los indicadores que Andes utiliza al momento de evaluar la calidad de un

roster corresponde a la calidad de vida de sus operarios. Se decidi, junto al rea de RRHH de la

empresa, que una vez que se cumplen todas las normas sindicales y legales solamente queda

asegurar la existencia de al menos 2 ocurrencias de das libres consecutivos al mes, para que la

planificacin cumpla con sus requerimientos. A continuacin se presentan los resultados de esta

medicin donde se puede apreciar el incremento de la asignacin deseada utilizando el nuevo

sistema.

Tabla 3: Comparacin de libres consecutivos mensuales.

Andes U. Chile

Personal Porcentaje Personal Porcentaje

2 Libres consecutivos al mes >= 2 419 52% 468 58%

Habiendo comprobado que la solucin entrega resultados aceptables por la empresa,

podemos enfocarnos en la reduccin efectiva de tiempo de trabajo. Se buscaba reducir el

tiempo consumido por este proceso, que inicialmente tomaba 3 semanas hbiles.

Una vez que el roster era completado en el sistema antiguo, se comenzaba el proceso deedicin y revisin que se prolongaba hasta 5 das antes del comienzo del mes. Esta revisin era

de gran importancia pues, al tratarse de un proceso manual en el que participaban varios

actores (RRHH, rea de Planning, rea de Capacities), la existencia de errores de transcripcin,

informacin desactualizada y/o errnea eran comunes.

Utilizando el nuevo sistema de planificacin desarrollado en esta memoria, la cantidad de

errores producto de transcripciones se redujo enormemente. Esto debido a que el proceso


41/74

36

completo de asignacin de turnos ocurre de manera automtica y la informacin debe seguir

nuevos estndares de formato y tiempos para ser aceptada. La cantidad de horas necesaria para

que el modelo tome la informacin generada y obtenga una asignacin aceptable vara

dependiendo de la cantidad de restricciones, de la cantidad de empleados y de la diferencia

entre esta dotacin y los requerimientos de personal. La estimacin de tiempos de la asignacin

para cada cargo puede ser vista en la siguiente tabla.

Tabla 4: Tiempos de generacin de roster para cada cargo

CargoTiempo (minutos)

Validacin Ejecucin Sistema Revisin Total Total (horas)

Camin de servicio 30 90 30 150 2,5

Cargoloaderista 60 120 60 240 4

Carrusel 30 90 30 150 2,5

Conveyor 90 270 60 420 7Coordinador PEQ 30 90 30 150 2,5

Coordinador SAT 30 90 30 150 2,5

Diecing 30 90 30 150 2,5

Jefe de Turno OPCO 30 90 30 150 2,5

Jefe de Turno Rampa 30 90 30 150 2,5

Monitor Cinta 30 90 30 150 2,5

Monitor Counter 30 90 30 150 2,5

Monitor de Vuelo 60 390 60 510 8,5

Monitor OPCO 30 90 30 150 2,5

Operario bomba de combustible 30 90 30 150 2,5Operario Counter 30 90 30 150 2,5

Operario PEQ 60 270 90 420 7

Operario Rampa 60 270 90 420 7

Supervisor PEQ 30 90 30 150 2,5

Taller 30 90 30 150 2,5

Towing 30 90 60 180 3

Tractorista Carga 30 90 60 180 3

Tractorista Carguero 30 90 60 180 3

Tractorista PEQ 30 90 60 180 3

Tractorista Rampa 30 90 60 180 3

Tractorista ULD 30 90 60 180 3

Total 930 3120 1140 5190 86,5

Estos resultados muestran que utilizando el nuevo sistema, se reduce el tiempo de

asignacin de 2 semanas, a menos de 4 das.


42/74

37

Los resultados obtenidos son producidos, directamente, por un modelo de optimizacin cuya

escritura, parametrizacin y lectura requieren de conocimientos avanzados de Optimizacin y

modelamiento matemtico. Sin embargo, gracias al presente sistema, el usuario final no

requiere de ningn tipo de conocimiento adicional. La carga de datos es transparente, sigue los

mismos estndares de manejo de datos que existe actualmente en la empresa y los resultados

corresponden a los estndares con los que se trabaja. El sistema queda a cargo de darle formatoa la informacin, de entregar al solver la informacin que el modelo de optimizacin requiere y,

una vez que se tiene la respuesta, de tomarla y darle un formato legible por un humano.


43/74

38

7. Conclusiones y Trabajo a futuro

Durante el desarrollo de este proyecto se trabaj en el diseo y la posterior implementacin

de un sistema de planificacin de personal. Este sistema maneja la informacin de

requerimientos de personal y de capacitaciones, licencias, vacaciones y requerimientos

especiales de los empleados de una empresa con los cuales se les genera una asignacinmensual de turnos.

Este trabajo fue documentado y se mantuvo dentro de los estndares de programacin y

nomenclatura especificados por la empresa y se llev a cabo a travs de constantes reuniones

con el personal de Andes en las que se detallaban los usos y necesidades que se requeran de la

solucin tecnolgica a desarrollar, en el subsiguiente trabajo en comprender y simplificar el

proceso completo, en idear las arquitecturas y estructuras de datos capaces de soportar dicha

informacin y, finalmente, desarrollar, probar y validar la solucin.

El sistema desarrollado entrega como input a un solver toda la informacin que requiere en

los formatos necesarios y obtiene como resultado un archivo que es ledo y cargado dentro de

la base de datos para su posterior gestin, entregando a un usuario las herramientas necesarias

para su revisin, medicin y, en caso de ser necesario, edicin a travs de las interfaces de

usuario que proporciona el sitio web.

Previa a la puesta en marcha en Andes, el sistema fue ampliamente probado, tanto por el

equipo de desarrollo del sistema computacional como por el equipo de modelamiento, para

comprobar que el sistema entregara los resultados esperados cuando finalmente se desplegara

en la empresa.

El desarrollo de la aplicacin present una serie de dificultades. En primer lugar el equipo de

trabajo no tena experiencia en el framework utilizado, pese a cumplir con las necesidades por

las que fue escogido. Esto llev a problemas en el aprendizaje y un leve retraso en el avance del

proyecto, aunque finalmente se logr manejar de manera adecuada la herramienta y obtener

los resultados que se esperaban, esto es, un menor tiempo de respuesta para producir los

cambios que requera el usuario.

En segundo lugar existieron problemas de comunicacin con la empresa. Al momento de

iniciar el proyecto ninguna de las personas con las que entablaron reuniones tena un

conocimiento completo y acabado del proceso real de rostering. Esto llev a muchos cambios

en los requerimientos iniciales, tanto del sistema de manejo de datos como para el modelo de

optimizacin que terminaron prolongando el proyecto por ms tiempo del propuesto

inicialmente y forzando al equipo a estar constantemente modificando los avances obtenidos.


44/74

39

A pesar de estas dificultades, sin embargo, se logr entregar un producto que cumple con las

necesidades requeridas y que fue validado tanto por el equipo especializado en el rea

matemtica, como por la propia empresa.

Producto de las nuevas herramientas que se le entregaron al rea de Planificacin, surgieron

nuevas ideas de parte de Andes. Teniendo en cuenta estas nuevas necesidades, en un futuro se

podra extender la herramienta para obtener todas o algunas de las siguientes opciones:

1. Mejores vistas de reportes: Segn lo requerido por Andes se procedi a generar una

serie de reportes simples (tablas) para manejar estadsticas del roster actual. Sinembargo ya que la informacin histrica de rosters pasados existe en la base de datosesta informacin podra ser mostrada de maneras visuales como grficos o de manerams segmentada haciendo cruces entre meses o incluso aos.

2. Paso a Desarrollo/Produccin: Actualmente el desarrollo de la aplicacin corresponde a

una prueba de concepto, una figura creada para comprobar la factibilidad de

proyectos de software sin la necesidad de entrar al flujo normal de certificacin de

proyectos de LAN. Sin embargo estaba contemplado la generacin de todos losdocumentos necesarios para iniciar el debido proceso de un proyecto en LAN.

3. Conexin con base de datos de RRHH: Actualmente, debido a la separacin existenteentre los servicios en ejecucin en Andes y los servidores de desarrollo de LAN, lacomunicacin entre las bases de RRHH y las necesarias por el sistema se encuentranseparadas. En un futuro, la base de datos del sistema podra ser homologada a su smilen Andes reduciendo la posibilidad de errores en el manejo de informacin.

4. Agregar el flujo del proceso extendido a la herramienta: La herramienta maneja distintostipos de usuario, pero esto slo filtra las capacidades de edicin a ciertas tablas. Como

una futura mejora al sistema se podra agregar el flujo que corresponde a la creacin delroster a nivel organizacional: Que el ciclo completo de captura de datos (rea RRHH),requerimientos (rea Capacity) construccin del roster (rea Planning) y revisin(Gerencia) est contenido en el sistema.

5.

Sistema para el manejo de turnos da a da: El sistema propuesto en la memoria cumplecon las funciones crticas: El manejo de datos para lograr generar una asignacinmensual, dicha generacin, y la edicin del resultado. Sin embargo, queda la opcin afuturo de expandir el Sistema para no slo planificar el mes, sino tambin para hacersecargo de las contingencias diarias.


45/74

40

8. Bibliografa y Referencias

[1] P. Brucker, R. Qu and E. Burke, Personnel scheduling: Models and complexity, European

Journal of Operational Research, no. 210, pp. 467-473, 2011.

[2] A. T. Ernst, H. Jiang, M. Krishnamoorthy and D. Sier, Staff scheduling and rostering: A reviewof applications, methods and models, European Journal of Operational Research, no. 153,

pp. 3-27, 2004.

[3] H. Hoogeveen and E. Penninkx, Finding Near-Optimal Rosters Using Column Generation,

Technical Report UU-CS-2007-002, 22 December 2006.

[4] O. Enterprise, Oracle Application Development FrameWork (ADF) Data Sheet, 2013.

[5] S. OBrien y S. Shmeltzer, Oracle Application Development Framework Overview, 2011.

[6] H. Mittelmann, Benchmarks for Optimization Software, 8 8 2012. [En lnea]. Available:

http://plato.asu.edu/bench.html. [ltimo acceso: 20 11 2012].

[7] B. Stroustrup, C++ Programming Language, 8 ed., 1998.

[8] M. Bazargan, Airline Operations and Scheduling, Segunda ed., Ashgate Publishing, 2010.

[9] R. S. Pressman, Ingeniera del Software: Un enfoque prctico, sexta ed., Mc Graham Hill,

2004.


46/74

41

Anexos:

A continuacin se presenta en detalle informacin del proyecto que, por ser demasiada

extensiva o especfica, no fue incorporada en el cuerpo principal de este documento. La

informacin corresponde a:

Casos de Uso.:El detalle de los Casos de Uso del sistema.

Interfaces de Usuario: Las interfaces diseadas para todas las vistas que conforman el

sitio web.

Diccionario de Datos: La descripcin detallada de las distintas tablas que componen la

base de datos del sistema.

Diagrama Base de Datos:Un diagrama completo de la base de datos implementada.

Formato de los archivos de entrada de datos: El formato de los archivos de datos que

deben ser importados al sistema para su funcionamiento.

A. Casos de Uso.

Caso de Uso: 1

Descripcin: El usuario desea generar un nuevo roster par el mes en planificacin

Precondiciones :

El mes que se desea generar es el mes que se est planeando (el mes siguienteal actual)

Flujo normal

El usuario ingresa al sistema por medio de un Login

Selecciona el mes que va a generar

Selecciona y sube al sistema los archivos necesarios para la generacin de un

rolSi los datos no son los adecuados pues necesitan algn tipo de correccin, sepasa a editarlos en una vista de edicin

En el momento que los datos sean satisfactorios, se guardan y se pasa a lasiguiente etapa.

Se seleccionan los cargos para los cuales se usara el modelo de optimizacin.Estos cargos tienen que tener datos en el sistema para el mes en curso

Se da inicio al proceso de generacin de roster para los cargos seleccionados

En la vista de resultados se puede editar a mano el rol, mostrando en tiemporeal los KPI

En caso que se deban generar cambios puntuales a los datos se debe abrir unpop-up que maneje la peticin

En caso de que los cambios a realizar sean masivos, se puede regresar a lavista de carga de datos sin necesidad de volver a lanzar el roster

Una vez satisfecho, se debe guardar el rol

Previa revisin del Rol con las otras reas relevantes se pasa a liberar el rolpara su impresin y envi a los empleados

Post-condiciones


47/74

42

La nica informacin vlida para la generacin automtica del Roster es lacontenida en las bases de datos que alimentan al modelo, no as lainformacin del resultado

Caso de Uso: 2

Descripcin:El usuario desea modificar el roster para el mes en planificacin

Precondiciones :Deben existir datos ya en el sistema y el mes a seleccionar debe ser el que seest planificando actualmente

Flujo normal

El usuario ingresa al sistema y selecciona el mes que se encuentra enplanificacin

Si existe el Rol se puede pasar a editar. En caso de que no exista, se debeproceder a crearlo a partir de datos en el sistema. Si no existen datos en elsistema para ese cargo, entonces se debe proceder a subirlos en primer lugar

Se realizan las modificaciones que se estimen necesarias

Si los cambios a realizar son numerosos o existi un cambio importante en losdatos del sistema, se puede pasar a editar los datos y volver a hacer funcionarel solver para generar un nuevo rol



Post-condiciones


Caso de Uso: 3

Descripcin: El usuario desea modificar un rol generado para un mes en curso

Precondiciones : Debe existir un rol ya generado y el mes debe ser el actual

Flujo normal

El usuario ingresa al sistema y selecciona el mes que se encuentra en curso

Si existe el Rol se puede pasar a editar. En caso de que no exista, se debeproceder a crearlo a partir de datos en el sistema. Si no existen datos en elsistema para ese cargo, entonces se debe proceder a subirlos en primer lugar

Se realizan las modificaciones que se estimen necesarias

Se selecciona personas o das que estarn fijos y que no sern modificados al

momento de lanzar nuevamente el solverSi los cambios a realizar son numerosos o existi un cambio importante en losdatos del sistema, se puede pasar a editar los datos y volver a hacer funcionarel solver para generar un nuevo rol.



Post-condiciones


48/74

43


Al terminar un rol, se debe seguir un protocolo por establecer para lacomunicacin de este con el resto de los interesados (ya sea por envo demails o impresin de los roles individuales)

Caso de Uso: 4

Descripcin: El usuario desea consultar o editar roles de meses anteriores

Precondiciones : Deben existir en el sistema los meses que se desean revisar

Flujo normal

El usuario ingresa al sistema y selecciona el mes

Se pasa a revisar el rol, realizndose las modificaciones que se estimenconvenientes

Al terminar la edicin, se puede guardar la informacin del roster

Post-condiciones


En caso de que se realicen cambios y se deseen guardar, estos son versionesdel mes correspondiente (mesXversion2), quedando siempre en el sistema elmes original inmutable.

Caso de Uso: 5

Descripcin: El usuario desea crear un rol para un mes futuro

Precondiciones :

El mes a seleccionar no debe ser un mes pasado, o el mes en curso o enplanificacin.

Flujo normal

El usuario ingresa al sistema por medio de un Login

Selecciona el mes que va a generar

Selecciona y sube al sistema los archivos necesarios para la generacin de unrol, si lo desea puede usar los datos de un mes en particular

Si los datos no son los adecuados pues necesitan algn tipo de correccin, sepasa a editarlos en una vista de edicin

En el momento que los datos sean satisfactorios, se guardan y se pasa a lasiguiente etapa

Se seleccionan los cargos para los cuales se usara el modelo de optimizacin.Estos cargos tienen que tener datos en el sistema para el mes en curso

Se da inicio al proceso de generacin de roster para los cargos seleccionados

En la vista de resultados se puede editar a mano el rol, mostrando en tiemporeal los KPI

En caso que se deban generar cambios puntuales a los datos se debe abrir unpop-up que maneje la peticin


49/74

44

En caso de que los cambios a realizar sean masivos, se puede regresar a lavista de carga de datos sin necesidad de volver a lanzar el roster

Una vez satisfecho, se puede guardar el rol

Post-condiciones

Todos los datos generados se guardan como versiones, ninguno corresponde acambios histricos o reales


Caso de Uso: 6

Descripcin: El usuario desea generar reportes sobre un roster

Precondiciones : Debe existir

Cf Campothesis Cv

Documents

Transcript of Cf Campothesis Cv