José Alberto Araúzo-Araúzo, José Manuel Galán-Ordax ... eficiente de carteras... · Gestión eficiente de carteras de proyectos. ... este modelo, los proyectos demandan parte

Organización y dirección de empresas

Dyna Septiembre 2009 • Vol. 84 nº6 • 71/72Articulo de investigación 1

Gestión eficiente de carteras de proyectos. Propuesta de un sistema inteligente de soporte a la decisión para oficinas técnicas y empresas consultorasJosé Alberto Araúzo-Araúzo, José Manuel Galán-Ordax, Javier Pajares-Gutiérrez, Adolfo López-Paredes 5311.99-5 Gestión de proyectos

RESUMENEn este artículo demostramos cómo una aproximación

inspirada en los procedimientos de asignación utilizados en losmercados financieros permite una asignación eficiente derecursos a proyectos en un entorno multiproyecto. Presentamosuna herramienta desarrollada para dar soporte en tiempo real alas necesidades de planificación y programación de la cartera deproyectos de una empresa de ingeniería o una empresaconsultora. Todo ello en un entorno dinámico donde la carterade proyectos, sus propiedades, así como el fondo de recursos ysus características cambian, bien por evolución de la estrategiade la compañía, por retrasos o sobre costes en alguno de losproyectos individuales, o simplemente por modificaciones enel entorno.

En el sistema propuesto, proyectos y recursos emulan aagentes económicos. Los proyectos, que son descritos mediantesus tareas y relaciones de precedencia, buscan recursos paraintentar finalizar en el plazo determinado. Los recursos estándotados de ciertas habilidades o competencias (conocimientos,fuerza de trabajo, etc.) para ejecutar alguna de esas tareas. Eneste modelo, los proyectos demandan parte del tiempodisponible a los recursos que disponen de las capacidades paraejecutar sus tareas. El precio establecido mediante una“subasta” refleja la relación entre la disponibilidad y la demandade las competencias asociadas al recurso.

Para demostrar la utilidad, se plantea un problema en el quemostramos cómo opera el sistema desarrollado. Este modelopiloto puede aplicarse en oficinas técnicas de ingeniería yempresas consultoras fácilmente, ayudando de forma integrada

ABSTRACT• In this paper, we show a “financial market inspired”

approach to resource allocation in multiprojectenvironments. This novel approach can give support toengineering and consultancy firms, engaged in projectportfolio planning and scheduling in dynamicenvironments. Project importance and resourcesavailability change over time because of changes in firmstrategy, because of individual project overruns or simply,as a result of environment changes. Therefore, resourcesneed to be re-allocated dynamically.

• In our methodology, projects and resources play the roleof economic agents. Projects are defined by means oftasks to be performed according to defined precedencerelations. Resources are endowed with skills andcompetences (knowledge, labour time, etc.) which arenecessary to perform tasks. Projects ask for resourcesand resources offer their capabilities depending on theirtime slot availability. An “auction” takes place and theprice of resources in a particular time-slot reflects therelation between availability and demand of resourcecapabilities.

• We describe an example to show how the methodologyworks. A pilot model can be used in Technical EngineeringOffices in order to support portfolio scheduling decisions.

• Key words: project portfolio management, Projectscheduling, multiproject environments, multiagentsystems, auction.

Recibido: 01/12/08 • Aceptado: 10/03/09

Gestión eficiente de carteras de proyectos.Propuesta de un sistema inteligente de soporte a ladecisión para oficinas técnicas y empresas consultoras.

Efficient project portfolio management. An intelligent decision support system for

engineering and consultancy firms

• José Alberto Araúzo-Araúzo Dr. Ingeniero Industrial Escuela Técnica Superior de Ingenieros Industriales Valladolid • José Manuel Galán-Ordax Dr. Ingeniero Industrial Escuela Politécnica Superior.Burgos• Javier Pajares-Gutiérrez Dr. Ingeniero Industrial Escuela Técnica Superior de Ingenieros Industriales. Valladolid• Adolfo López-Paredes Dr. Ingeniero Industrial Escuela Técnica Superior de Ingenieros Industriales Valladolid

jmhernandez

Text Box

jmhernandez

Note

Escuela Técnica Superior de Ingenieros Industriales de Valladolid

jmhernandez

Note

Escuela Politécnica Superior de Burgos

jmhernandez

Note

Investigación


Dyna Septiembre 2009 • Vol. 84 nº6 • 71/722 Articulo de investigación

Gestión eficiente de carteras de proyectos. Propuesta de un sistema inteligente de soporte a la decisión para oficinas técnicas y empresas consultoras

José Alberto Araúzo-Araúzo, José Manuel Galán-Ordax, Javier Pajares-Gutiérrez, Adolfo López-Paredes

a la toma de decisiónes sobre la composición y laprogramación de carteras de proyectos.

Palabras clave: gestión de la cartera de proyectos,programación de proyectos, entornos multiproyecto,sistemas multiagente, subasta.

1.- GESTIÓN DE CARTERAS DE PROYECTOSLa literatura sobre dirección de proyectos se ha centrado

fundamentalmente en la gestión de proyectos individuales.Pero en la práctica, las empresas trabajan generalmente enentornos multiproyecto, donde varios proyectos se estánejecutando simultáneamente usando para ello un conjuntolimitado de recursos.

Un ejemplo de este tipo de entornos es una oficina deproyectos de ingeniería (Martínez et al., 2001) o unaempresa consultora, donde trabajan personas dotadas dediferentes habilidades que realizan ciertos tipos de tareas(cálculos, redacción, realización de planos, revisión, etc.).En una oficina de este tipo, los nuevos proyectos seintegran en la cartera de la empresa a medida que el clientelos va demandando. Cada proyecto exige la realización deun conjunto de tareas, ejecutadas en un orden concreto yque sólo pueden ser llevadas a cabo por personas queposean las habilidades necesarias.

En estos entornos, los gestores deben priorizar yseleccionar los proyectos (de entre los propuestos por losclientes) que se añadirán a la cartera, teniendo en cuentalos márgenes esperados y el estado de saturación de lospuestos de trabajo (recursos). Además, deben repartir lastareas entre los diferentes trabajadores, priorizar lostrabajos y programar su ejecución. Todo ello, buscando ellogro de los objetivos operativos y estratégicos de laempresa

Debido a la adición de nuevos proyectos, a cambios enla estrategia corporativa, o simplemente a la informaciónobtenida de la retroalimentación del sistema, la lista deprioridades cambia a lo largo del tiempo. Todos estoscambios unidos a las perturbaciones que suceden en losrecursos (fallos en equipos, retrasos en la ejecución de los

trabajos, etc.) obligan a la reasignación y reprogramaciónde tareas, buscando de nuevo la mejor forma de conseguirlos objetivos de la empresa.

Las perturbaciones y los cambios en la cartera deproyecto pueden suponer nuevos conflictos entre proyectos(p.e., varios proyectos compiten por el mismo periodo detiempo de un mismo recurso). Por este motivo la direccióneficiente de carteras de proyectos requiere del desarrollo desistemas inteligentes de soporte a la decisión, que facilitenla toma de decisiones en cuanto a asignación de recursos yprogramación de tareas, siempre teniendo en cuenta lalimitación de recursos, y el cumplimiento del plazo de losproyectos de la cartera.

Desafortunadamente, la investigación sobre laasignación de recursos en entornos multiproyecto no haproporcionado una solución suficientemente robusta yflexible para los casos más generales (Anavi-Isakow &Golany, 2003). En Hans et al (2007) se puede encontrar unarevisión de la literatura existente, centrándose en modelosde asignación jerárquicos (primero se asignan recursos acada proyecto según su importancia estratégica, yposteriormente, cada proyectos gestionaindependientemente los recursos que le han sidoasignados). Además, propone una plataforma genérica deprogramación y control de proyectos que basada en laselección de diferentes métodos en función de cuestionesorganizacionales. En Kao et al (2006) se propone unsistema dirigido por eventos para desarrollar unaplataforma de decisión trade-off para la programación yreprogramación. Cohen et al. (2004) analizan elcomportamiento del método de la cadena crítica de Goldratt(1997) en entornos multiproyecto.

En este artículo proponemos un sistema inteligente desoporte a la decisión (IDSS) que opera en tiempo real. Setrata de una nueva aproximación para la programacióndinámica de tareas en tiempo real en entornosmultiproyecto ejecutados por una organización dada. Conesta herramienta seremos capaces de analizar algunos delos problemas más difíciles relacionados con la gestión dela cartera de proyectos: la determinación de los recursosociosos y sobrecargados; la detección de los recursos clave

5311.99-5 Gestión de proyectos

Los gestores deben priorizar y seleccionar los proyectos (de entrelos propuestos por los clientes) que se añadirán a la cartera,teniendo en cuenta los márgenes esperados y el estado desaturación de los puestos de trabajo (recursos).



Gestión eficiente de carteras de proyectos. Propuesta de un sistema inteligente de soporte a la decisión para oficinas técnicas y empresas consultorasJosé Alberto Araúzo-Araúzo, José Manuel Galán-Ordax, Javier Pajares-Gutiérrez, Adolfo López-Paredes

y la de las habilidades que deben incrementarse en elsistema; la conveniencia de incorporar nuevos recursos; elanálisis del papel de la flexibilidad de los recursos, o lo quees lo mismo, la posibilidad de desempeño de variashabilidades por un mismo recurso; el efecto de adición oeliminación de proyectos; el cambio de prioridades entiempo de ejecución; etc.

El resto del artículo se organiza como sigue: primeropresentamos la metodología que soporta el IDSS quehemos implementado. A continuación definimosformalmente el problema que estudiamos: la programaciónde la cartera de proyectos con posibilidad de rechazo, y conlimitación de recursos. En las siguientes seccionesdesarrollamos el modelo multiagente subyacente, y losresultados obtenidos en un periodo de simulación.Finalmente presentamos las conclusiones y extensiones denuestro trabajo.

2.- SISTEMAS MULTIAGENTE Y ENTORNOSMULTIPROYECTO.

Los proyectos se caracterizan por su complejidadestática (existen muchos elementos y dependencias), porsu incertidumbre (sobre la disponibilidad de recursos,duración de las tareas), por el comportamiento dinámico(cambios en el alcance del proyecto, incorporación detareas, reprogramación) y por su natural distribución (cadaoperación puede ser ejecutada por diferentes recursos y endiferentes localizaciones geográficas).

Todas estas características se ven intensificadas en elcaso de entornos multiproyecto. Mas proyectos implica máscomplejidad estática, más incertidumbre, más complejidaddinámica, y más dispersión geográfica ya que no sólo lasactividades y los recursos estarán distribuidos, tambiénpueden estarlo la dirección de cada proyecto.

Dentro de la inteligencia artificial distribuida existe unparadigma denominado sistema multiagente, que resultamuy útil para analizar y diseñar nuestro sistema. Lossistemas multiagente se han concebido precisamente paraabordar problemas con características similares al nuestro.Estos sistemas son adecuados para tratar problemas que secaracterizan por ser complejos, abiertos (los componentesque aparecerán en el sistema no se conocen con antelación,pueden cambiar a lo largo del tiempo, son altamenteheterogéneos y dinámicos), dinámicos, estocásticos yubicuos (la actividad y la toma de decisión se distribuye alo largo de toda la estructura del sistema) (Jennings &Wooldridge, 1995; Pavón & Pérez, 2005; Wooldridge,2002).

Un sistema multiagente está formado por ciertasentidades software a las que dotamos de capacidad de

interaccionar entre ellas y con un entorno. Como objetos1

que son, poseen un estado (datos, conocimiento); peroademás son autónomos (no sólo actúan en base ainstrucciones, poseen además reglas para la toma dedecisión autónoma); reactivos (reaccionan ante estímulosexternos); proactivos (tienen objetivos propios y realizansus propios planes para conseguirlos); y sociales(interaccionan con otros agentes). Esta forma tan directa deabstraer los sistemas ha favorecido el desarrollo de sistemasbasados en agentes en múltiples campos (véase porejemplo, Pajares et al. (2004), López et al. (2005), Pascualet al. (2006), Galán et al. (2008), Posada & López (2008))

En el caso particular de los entornos multiproyecto, lasentidades que son susceptibles de ser abstraídas comoagentes pueden ser las tareas, los recursos, los proyectos,etc. Este diseño permite distribuir la gestión del sistema encomponentes elementales directamente identificables en laorganización que es objeto de estudio. De esta forma sefacilita el diseño del sistema de información, así como sumantenimiento y su posible adaptación a escenarios noprevistos inicialmente. Dado que el sistema de informaciónse distribuye de acuerdo a la estructura física uorganizacional del entorno, cualquier cambio en estaestructura es fácilmente trasladable al sistema de gestión(Araúzo et al., 2008).

Estas aproximaciones descentralizadas se han propuestopara la gestión de proyectos desde la década pasada (Yan etal., 2000), pero es en los últimos años cuando estánrecibiendo un creciente interés, especialmente aquellas quese basan en analogías con los mercados competitivos(Clearwater, 1996). Recientemente, Lee, Kumara yChatterjee (Kumara et al., 2002; Lee et al., 2003) hanpropuesto un sistema multiagente para la programacióndinámica de tareas en un entorno distribuido de múltiplesproyectos utilizando para ello mecanismos de mercado. Enla misma línea se encuentra el trabajo de Confessore et al(2007), donde se describe un mecanismo iterativo desubasta combinatoria que resuelve el mismo problema.

Otros ejemplos de aproximaciones basadas en agentesen el campo de la dirección de proyectos se puedenencontrar en las publicaciones de Kim et al. (Kim et al.,2000; Kim & Paulson, 2003b; Kim & Paulson, 2003a; Kimet al., 2003) de Wu and Kotak (2003) o de Cabac (2007).Nuestro trabajo continua con esta línea de investigación,centrándose concretamente en el uso de la metáfora demercado y de mecanismos de mercados para el desarrollode sistemas multiagente que ayuden a los gestores deproyectos a la toma de decisión sobre el uso de los recursos,y sobre la composición de la cartera. Este trabajo añade otropaso en el uso de las herramientas proporcionadas por lossistemas multiagente como sistemas de soporte para ladecisión en entornos multiproyecto.


1 En sentido computacional





3.- PROGRAMACIÓN MULTIPROYECTO CONPOSIBILIDAD DE RECHAZO.

La formalización del problema de programaciónmultiproyecto con posibilidad de rechazo de proyectos queabordamos en este trabajo es el siguiente:

En cualquier instante t existen I proyectos en el sistema,cada uno de ellos denotado mediante i (Figura 1). Cadaproyecto se caracteriza por un valor Vi, que puedeinterpretarse como el pago que un cliente hace por elproyecto o como la valoración que un proyecto internotiene para la organización, un peso wi que representa laimportancia estratégica del proyecto, una fecha de entregadeseable Di, un fecha de entrega límite Di

* que no puede serexcedida, una fecha de llegada del proyecto al sistema Bi,y una fecha de respuesta límite Ri que es la fecha mas tardíapara decidir si el proyecto es rechazado o incluido ennuestra cartera. El sistema es dinámico: los proyectosllegan al sistema o son rechazados mientras otros mientrasotros proyectos se están ejecutando.

Cada proyecto i consiste en Ji actividades o tareas, cadauna de ellas denotada por los subíndices ij donde i{1, 2,…,I} y j{1, 2,…, Ji}. Cada tarea lleva asociada una duraciónestándar dij (duración de la actividad en un recurso deeficiencia normal).

La empresa gestiona un conjunto M de recursosencargados de completar las actividades de los proyectos.Cada recurso m {1, 2, 3…M} sólo podrá ejecutarsimultáneamente una única tarea, que una vez comenzadadeberá ser finalizada.

Para llevar a cabo los proyectos pueden ser necesariasun conjunto H={h1, h2,...,hK} de habilidades por parte delos recursos. Cada recurso está dotado de un ratio de costepor unidad de tiempo Cm y de un subconjunto Hm dehabilidades que es capaz de desarrollar. Los recursos tienendiferente grado de pericia o destreza para realizar cadahabilidad. Así, la capacidad de trabajo de los recursos sepuede representar mediante un vector de destrezas enhabilidades del recurso m em=(em1, em2,…,eK) dondeemf ≥ 0 y mide la destreza del recurso m para realizar lahabilidad f. Si emf = 0 entonces el recurso no poseerá la

habilidad kf, si 0<emf < 1 el recurso exhibirá la habilidadkf ineficientemente, si emf = 1 lo hará con eficienciaestándar, y si emf > 1 su eficiencia será elevada.

Cada actividad está asociada a una habilidad k(ij) H.Una actividad ij asociada a una habilidad k(ij) puede serrealizada por el recurso m si y sólo si em,k(ij)>0, es decir,si el recurso posee una destreza no nula en la habilidadnecesaria para desarrollar la actividad ij.

La duración de la tarea ij asignada a un recurso m (dijm)se calculará en función de la duración estándar de laactividad (dij) y de la eficiencia con la que el recursodesempeña la habilidad necesaria k(ij), por lo que laduración de la actividad dependerá del recurso al que se laasigna según la expresión dijm=dij/em,k(ij).

En nuestro primer modelo asumiremos, para facilitar lainterpretación de los resultados, que dentro de cada uno delos proyectos sus actividades se deben ejecutarsecuencialmente, una tras otra, según el orden indicado porel subíndice j. La eliminación de este supuesto no supondríaañadir problemas conceptuales al modelo, pero aumentaríala complejidad de alguno de los algoritmos incorporados.En todo caso, esto no impide extrapolar los resultadosobtenidos a casos más complejos.

También supondremos que las tareas, una vezcomenzadas, no se podrán interrumpir. El recurso trabajarásobre la actividad asignada hasta que la finalice, despuéspodrá pasar a ejecutar otra tarea.

Se incluye la posibilidad de reasignación de recursos entiempo real cada vez que un nuevo proyecto llega al sistemao cuando los cambios del entorno lo justifiquen (pérdida oincorporación de un recurso, anulación de un proyecto,etc.).

La eficiencia global del sistema se evaluará medianteel beneficio medio obtenido por unidad de tiempo. Secalculará de acuerdo a la siguiente expresión, para unhorizonte temporal T.

Expresión 1


Figura 1. Entorno Multiproyecto.

Debido a la adición de nuevos proyectos, acambios en la estrategia corporativa, osimplemente a la información obtenida dela retroalimentación del sistema, la lista deprioridades cambia a lo largo del tiempo.




donde i indica cada uno de los proyectos finalizadosdurante T, y Cost(i) es el coste asociado al proyecto. Estecoste tiene dos componentes, el coste directo de uso de losrecursos y un coste asociado al retraso.

Expresión 2

El primer término se corresponde con el coste deltiempo de uso los recursos para ejecutar cada tarea ij.cm(i,j) denota el coste por unidad de tiempo del recursom(i,j), donde m(i,j) indica el recurso seleccionado pararealizar la operación j del proyecto i. El segundo término esel coste de retraso asociado al proyecto, donde Fi es lafecha real de finalización del proyecto. Este coste será cerosi el proyecto finaliza antes de la fecha deseada Di, si elproyecto finaliza entre la fecha deseada y la fecha límite elcoste será proporcional al cuadrado del retraso, y si la fechade finalización supera la fecha limite Di

* el coste tenderá ainfinito. La consideración de los costes por retraso de formacuadrática implica que los altos retrasos son mucho máscostosos que los retrasos moderados. De esta de formanuestro sistema va a penalizará altamente los retrasoselevados, optando por soluciones sin retrasos extremos.Además esta forma de proceder garantiza una mejorconvergencia del proceso de subasta.

El retraso sobre el plazo límite, se penaliza con un costeinfinito para no considerar durante el proceso deprogramación y selección de proyectos, proyectos conprogramas que violen este plazo. Un vez que el proyectoha sido aceptado, el sistema hará todo lo posible para queno se supere el plazo límite, pero puede haber algunos casosen los que esto no sea factible (retrasos en la ejecución deoperaciones, absentismo,…). En esos casos se finalizarátras la fecha límite y se computarán los retrasos y sus costesa partir de la fecha de finalización deseada.

Se considera la posibilidad de rechazar proyectos, loque puede suceder por los siguientes motivos.

• El valor aportado por el proyecto no compensa loscostes.

• El proyecto no se puede finalizar antes de su fechalímite Di

*.• El impacto sobre la programación del resto de

proyectos es inaceptable. Esto puede suceder porejemplo, cuando la inclusión del nuevo proyecto

obligaría a retrasar los proyectos comprometidoshasta superar su fecha Dc

*, o cuando la inclusión deun nuevo proyecto incrementaría los costes deretraso de los otros proyectos más que el margenobtenido por la inclusión del nuevo.

La cartera puede estar compuesta por proyectos dediversa naturaleza (aquellos realizados para clientes,proyectos de reorganización, de I+D, etc.). Puesto que loscriterios de decisión utilizados son fundamentalmenteeconómicos, para que el sistema pueda decidir sobre laejecución de proyectos internos, estos se deberían valoraren términos monetarios. Si además algún proyecto tieneventajas añadidas para la organización, como la captaciónde un cliente, etc, éstas deberían valorarse en términoseconómicos (coste de oportunidad que se está dispuesto aasumir por ese concepto). Si los proyectos y sus ventajasadicionales son de difícil valoración, nuestro sistema tieneposibilidad de incluirlos sin valorar y forzar al sistema suaceptación.

Inicialmente, no se contempla la posibilidad desubcontratar tareas, aunque el sistema puede extendersepara la toma de decisiones sobre subcontratación de tareas,así como para la selección entre posibles subcontratistas,con sólo conocer los costes asociados a la subcontratación,la posible duración de las tareas subcontratadas y ladisponibilidad temporal del subcontratista para realizarlas.Tampoco se contempla la posibilidad de establecer plazospara hitos intermedios como pueden ser los “entregables”.No sería muy complicado eliminar este supuesto, ya quesolo conlleva la introducción nuevas restriccionestemporales que afectan a la programación local de losproyectos. En el estado inicial del prototipo no se hanintroducido estas funcionalidades por simplicidad, y parafacilitar el análisis y la verificación de la robustez de laaproximación propuesta”.

4.- UN SISTEMA MULTIAGENTE PARA LA GESTIÓNONLINE DE UNA CARTERA DE PROYECTOS.

Tradicionalmente los problemas de programación sehan resuelto off-line mediante un sistema centralizado detoma de decisión, y usando para ello, un modelo deoptimización global. Al contrario de lo que sucede con esteparadigma tradicional, en nuestro sistema existirán variasentidades independientes capaces de tomar decisiones;entidades que serán modeladas como agentes.Consideraremos dos tipos de agentes, agentes Proyecto yagentes Recurso (Figura 2).

En un determinado momento el sistema poseerá tantosagentes Proyecto como proyectos se hayan propuesto. Cadauno de ellos representa a un proyecto concreto y poseeráinformación sobre sus operaciones, relaciones deprecedencia, habilidades necesarias, valor, fechas de






entrega y estado de ejecución (grado de ejecución de lastareas planificadas). El objetivo de estos agentes serácompletar el proyecto, y para conseguirlo, acordarán conlos recursos planes de actuación (programa local delproyecto), supervisarán el cumplimiento de estos planes, ylos modificarán cuando la situación lo exija.

En el sistema existirán también tantos agentes Recursocomo recursos sean considerados. Estos poseeráninformación sobre sus competencias, disponibilidad, costetemporal y sobre su estado (grado de ejecución de las tareaspendientes). Los agentes Recurso tendrán como objetivoconseguir trabajo y ocupar así su tiempo disponible. Estetrabajo lo obtendrán de los proyectos, a través de acuerdosque se formalizarán mediante contratos, que conformarán lalista de tareas del recurso o programa local del recurso.

En nuestro sistema multiagente el sistema de toma dedecisión es ubicuo, está distribuido entre todos los agentes,es decir, cada agente crea su propio programa localteniendo en cuenta para ello sus propios objetivos y supropia información. Esta forma de proceder puede originarprogramas locales incompatibles (varios proyectosprograman el uso de un mismo recurso durante el mismoperiodo), e ineficientes a nivel global (se desestiman losproyectos más rentables, se producen retrasos en losproyectos más importantes, etc.). Resulta por tantonecesario establecer un mecanismo de interacción entreagentes que minimice estos problemas. Este mecanismo deinteracción se basa en una metáfora de mercado.

Para establecer la metáfora comenzaremos porsubdividir los periodos de disponibilidad de los recursos enpequeños intervalos de tiempo o unidades temporales quedenominaremos “slots de tiempo” (Figura 3). Cada “slottemporal” de cada recurso se modelará como un bien queel recurso desea vender y los proyectos desean comprar

Con esta analogía, un programa local será unaasignación de un conjunto de “slots de tiempo” a unproyecto. Dado que en los mercados competitivos, seproduce bajo ciertas condiciones una asignación óptima derecursos, se propone utilizar los mecanismos observados

en estos mercados (subastas) para diseñar las interaccionesentre agentes Proyecto y agentes Recurso, de forma que laasignación de slots a proyectos se realice de la forma máseficiente posible. Cada agente Proyecto actuará como uncomprador en un mercado donde adquirir tiempo (slots) delos agentes Recurso, y donde estos intentarán vender sutiempo al máximo precio posible. Cada agente Proyecto,optará por un conjunto de slots que le permitan conseguirsus objetivos al mínimo coste. Es decir, cada agenteProyecto seleccionará un paquete de slots que le permitanejecutar sus operaciones pendientes y además que minimiceel coste de la expresión 3.

TCi : coste total del proyecto i.pmt : precio del slot temporal (t) del recurso (m)Zi : paquete de slots de tiempo seleccionados por el

proyecto (i)

Expresión 3

Para seleccionar el paquete de slots adecuado, losagentes Proyecto utilizan un algoritmo de programacióndinámica que evalúa el coste de todas las posiblescombinaciones de slots que son adecuadas para ejecutar susoperaciones (Wang et al., 1997). Si algún proyecto nopuede encontrar un conjunto de slots con los que puedaejecutar el proyecto antes de Di

*, con un coste menor a suvalor (Vi), entonces no seleccionará ningún conjunto deslots. Esto significará que el proyecto no es rentable en lacorrespondiente iteración del proceso de subasta.

Cada agente Recurso determina el precio de sus slotstemporales con el propósito de reducir los conflictos en eluso de recursos y maximizar su margen. Para ello se sigueun procedimiento basado en el algoritmo de optimizacióndel subgradiente (Zhao et al., 1999), que en términos desubasta se puede interpretar como sigue. Cuando comienzala subasta el Recurso valora todos sus slots temporales a unprecio mínimo que no se puede reducir (coste mínimo) que


Figura 2. Sistema multiagente propuesto.

Figura 3. Metáfora de Mercado.




será igual al coste del slot temporal. Después, cuando cadaagente Proyecto ha seleccionado el paquete de slotstemporales adecuado (según el procedimiento descritoanteriormente), los recursos incrementarán el precio de losslots donde existe conflicto (más de un proyecto haseleccionado el slot temporal) y reducirán los precios(nunca por debajo del coste mínimo) de los slots temporalesno demandados. Una vez se hayan ajustado los precios porparte de los recursos, los proyectos volverán a realizar suspropios programas locales (selección de slots temporalesmás satisfactorios). Tras ello, los recursos volverán a ajustarlos precios, y así iterativamente. El proceso de subastacontinúa indefinidamente.

Al comienzo de la subasta el precio de cada slottemporal será igual a t cm (tamaño del slot temporal porel coste temporal asociado al recurso). En el resto de lasubasta los precios de los slots temporales se ajustaránsegún la expresión 4.

Mediante el mecanismo de subasta descritoanteriormente, los agentes Proyecto elaboran programascompatibles y globalmente eficientes. Además, al mismotiempo, los agentes interactúan a través de un procesocomplementario con el que realizan contratos en firme;contratos que estarán basados en los programas localesrealizados en el proceso de subasta. Esos contratosdeterminan programas en firme para las tareas más

inmediatas. Cuando esos contratos han sido realizados, losagentes Proyecto no considerarán nunca más lasoperaciones asociadas en los procesos de subasta.

Dependiendo del grado de ajuste de los precios a lascondiciones reales del sistema, los programas locales seránmás o menos compatibles y globalmente eficientes. Si en elmomento de realizar los contratos en firme existenincompatibilidades, éstas se eliminarán usando para elloreglas heurísticas. Aunque esto no garantice la eficienciaglobal, sí que asegurará la compatibilidad de los programas.

En las Figuras 4 y 5 se muestran los diagramas de flujoque representan el funcionamiento básico de cada tipo deagente. Obsérvese que cada agente posee dos flujos básicosque se ejecutan en paralelo; mientras el flujo de la derecharepresenta las actividades relacionadas con laprogramación, el de la izquierda describe las tareas deejecución y control.

En los agentes Proyecto (Figura 4), el flujo deprogramación esta destinado a la elaboración de programaslocalmente óptimos para unos precios determinados de losslots temporales de los recursos. El agente está a la esperade precios, y cada vez que recibe nuevos precios para losslots de los recursos, calcula un nuevo programa local queserán almacenados en ‘Programa’. Se considerará que untipo de programa local es descartar el proyecto.


Expresión 4

En nuestro sistema multiagente el sistema de toma de decisión esubicuo, está distribuido entre todos los agentes, es decir, cadaagente crea su propio programa local teniendo en cuenta paraello sus propios objetivos y su propia información.





De forma paralela a este proceso de elaboración deprogramas, los agentes Proyecto gestionarán la ejecuciónde las actividades, y ello, según los programas elaborados.Al crearse el agente y tras haberse inicializado la base dedatos de tareas pendiente y fecha de comienzo, el agentecomenzará esperando a la fecha de comienzo del proyecto.Cuando llegue este momento, el agente Proyecto,comprobará el programa local más actual elaborado. Si esteprograma sugiere la desestimación del proyecto, se

eliminarán las tareaspendientes de la base dedatos y se elimina el agentedel sistema. Si por elcontrario el programa nosugiere desestimar elproyecto, el agentecontinuará proponiendo a unrecurso la ejecución de latarea indicada en el programalocal entre las fechasseñaladas por dichoprograma.

Tras la elaboración de lapropuesta, los agentesProyecto se la envían alagente Recursoseleccionado. Si el agenteRecurso desestima lapropuesta, se realizará unanueva. Si se acepta, se habráproducido un contrato enfirme, y entonces el agentequedará a la espera de lanotificación de su ejecución.Además, el agente elimina latarea del conjunto de tareaspendientes y modifica lafecha de comienzo para losnuevos programas locales.Cuando la tarea se hayaejecutado, el agente Proyectorecibirá una notificación porparte del recurso, entoncescomprobará si quedan tareaspendientes; si es así sevolverá a realizar propuestaspara estas tareas, si no, laejecución del proyecto habráfinalizado y el agente seeliminará.

En la Figura 5 se tiene elflujo de control de losagentes recurso. En este casoel flujo de programación estádedicado al establecimiento y

actualización de los precios de los slots temporales delrecurso. Ello lo hace en función de los programas localesrecibidos de los agentes proyecto siguiendo elprocedimiento explicado con anterioridad. El flujo deprogramación y control hace referencia a la aceptación yrechazo de propuestas de trabajo recibidas desde losagentes proyecto, así como a la ejecución de estos trabajos.


Figura 4. Diagrama de flujo de los agentes Proyecto.




5.- CASO DE ESTUDIO

En esta sección mostraremos algunas simulaciones queilustran cómo funciona el IDSS desarrollado, centrándonosen el manejo de la flexibilidad, es decir en el efecto delreparto de las habilidades entre los recursos del entornomultiproyecto.

Consideraremos tres recursos (R1, R2 y R3), queposeen respectivamente las habilidades C1, C2 y C3. En latabla 1 se muestra una cartera de seis proyectos con susoperaciones. Cada tarea es caracterizada por la habilidadque es necesaria para ejecutarla así como por su duración

estándar. Cada proyecto tiene además:una fecha de llagada (la fecha en la queel proyecto se incluye en el sistema,una fecha de comienzo, de lasactividades (si el proyecto se desestimadebe ser antes de esta fecha), una fechade entrega deseable (Di) y una fecha deentrega límite (Di

*).En la Figura 6 se muestra la

evolución del sistema (los ejeshorizontales representan el paso deltiempo) y la evolución de Gap deDualidad (gráfica superior de la Figura6). El gap de dualidad es una medida dela convergencia del proceso de subasta(Luh, Hoitomt, 1993). En losmomentos de tiempo donde el gap dedualidad es bajo, el proceso de subastaha convergido a unos precios de cuasi-equilibrio y por lo tanto los programaslocales realizados bajo estascondiciones son bastante compatibles yglobalmente eficientes. Las gráficasinferiores muestran, para cada recursoun diagrama de Gantt de los trabajosrealizados por el recurso, y además,sobre el gráfico de Gantt, los precios delos slots temporales a los que se harealizado la contratación.

Obsérvese que cuando los primerosproyectos son incluidos en el sistema,

el gap de dualidad es elevado, pero entonces, a medida queel proceso de subasta se ejecuta, los precios se estabilizany el gap de dualidad comienza a disminuir. Pero alincorporar nuevos proyectos al sistema en el instante detiempo 30, el gap de dualidad aumenta. Esto es debido aque los precios en ese momento no son representativos delnuevo estado del sistema (nuevos proyectos se hanincorporado). Tendrá que pasar un tiempo hasta que losprecios se vuelvan a ajustar a las nuevas condicionesmediante el mecanismo de mercado. Después, cuando losprecios se han desplazado hasta un estado de cuasi-equilibrio el gap de dualidad disminuye de nuevo.


Figura 5. Diagrama de flujo de los agentes Recurso.

Project Tasks Arrival date Starting Date Di Di* Value

Task 1 Task 2 Task 3P1 C1 50 C2 10 C3 20 -30 0 120 180 2500P2 C3 10 C1 60 -30 0 180 240 3500P3 C2 15 C1 50 -30 0 120 180 7000P4 C3 20 C1 45 C2 10 30 120 240 270 4000P5 C2 15 C3 10 C1 60 30 120 240 270 3000P6 C3 10 C2 20 C1 50 -30 0 120 180 5000

Tabla 1. Cartera de proyectos dinámica.





El hecho de que en el experimento el gap de dualidad semantiene con valores mínimos significa que las decisionesse han tomado de forma bastante eficiente (cuasi-óptima).El valor total obtenido (valor de proyectos ejecutadosmenos costes por retrasos y costes de recursos) es de 19402.Para ello se ha tenido que desestimar el proyecto P5. Nóteseque aunque este proyecto tiene un alto valor, éste ha entradoen el sistema cuando otros proyectos, algunos de menosvalor, ya estaban aceptados (P1, P2, P3 y P6) y por lo tantono se podían rechazar. Solo se podía optar entre rechazar elP4 y el P5.

La simulación no sólo muestra la programacióndinámica y el rechazo de proyectos, sino también lavaloración de los recursos. Por ejemplo, en la figura 6, los

precios de los slots temporales del recurso R1 son elevadosen todo el periodo de planificación. Esto significa que lashabilidades que posee el recurso son muy valoradas (elrecurso es un cuello de botella), de esta forma si la empresadesea aumentar su ganancia realizando más proyectos deeste tipo y nivelando el uso de recursos, podría intentarcapacitar a los otros recursos para poder exhibir lashabilidades del recurso R1, o bien introducir nuevosrecursos similares al recurso R1. Por otro lado, los preciosde los recursos R2 y R3 son bajos; aunque realizan algunasoperaciones, están ociosos la mayor parte del tiempo.

En el caso de estudio, resulta interesante analizar elcomportamiento del sistema cuando se aumenta el rangode habilidades de los recursos R2 y/o R3. En el caso de que


Figura 6. Evolución del sistema para el caso de estudio. Tij denota tarea j del proyecto Pi

Figura 7. Evolución del sistema para el caso de estudio con habilidades del recurso R2 incrementadas.




los recursos fuesen humanos, esta capacitación adicionalpodría corresponderse, por ejemplo, a la asistencia de losrecursos a un programa de formación. En la Figura 7 semuestra el comportamiento del sistema cuando el recursoR2 además de poseer su habilidad inicial C2, también poseela C1.

Comparando el resultado de la simulación con el delexperimento previo, se puede apreciar cómo los precios delos slots temporales han aumentado en el recurso R2 y handisminuido en el recurso R1. Algunas tareas que en elexperimento anterior eran ejecutadas por R1 ahora lo sonpor R2. Esto muestra que el sistema ha sido capaz deaprovechar la capacidad del recurso R2 para mejorar laeficiencia global. Ahora el proyecto P5 es aceptado y elbeneficio total obtenido se aumenta de 19402 a 24039, unaumento superior al 23%.

6. CONCLUSIONESAunque la literatura sobre dirección de proyectos se ha

centrado fundamentalmente en el caso de proyectosindividuales, en la práctica las empresas trabajanfrecuentemente con dinámicas y complejas carteras deproyectos que comparten un conjunto de recursos. A estossistemas se los denomina entornos multiproyecto.

Para la gestión de estos sistemas, nosotros proponemosun sistema multiagente y un mecanismo programación ycontrol on-line inspirado en mercados coordinadosmediante subastas. Los proyectos necesitan completar sustareas y por ello compiten por los recursos que exhiben lascapacidades necesarias para realizar dichas tareas. A travésde un proceso de subasta emergen unos precios del usotemporal de cada recurso, precios que son utilizados porlos proyectos para elaborar programas propios compatiblesentre si y globalmente eficientes.

En el artículo se muestra algunas de las posibilidadesque la aproximación propuesta ofrece para el soporte a latoma de decisión en entornos multiproyecto. El sistemaasigna recursos a las tareas de los proyectosdinámicamente, y ayuda además a la toma de decisiones desi se debe rechazar algún proyecto teniendo en cuenta paraello el valor aportado por los proyectos y el estado delsistema.

También se muestra cómo los precios aportaninformación sobre la criticidad que tienen los diferentesrecursos para el desempeño de la cartera de proyectos. Losprecios permiten valorar en tiempo real, si se debe adquirirmás recursos de un tipo durante un cierto periodo detiempo, o si se debe tratar de dotar con ciertas capacidadesadicionales a ciertos recursos.

Nuestra aproximación contribuye a rellenar el hueco deliteratura existente entre la gestión de cartera de proyectos–generalmente centrada en estrategia corporativa yfinanzas– y el trabajo en dirección de proyectos –

fundamentalmente dedicado a aspectos operacionales comola asignación de recursos y la programación–.

El objeto último de nuestro trabajo es conseguir unsistema operativo en entornos reales genéricos. Para ellosería necesario relajar algunos de los supuestossimplificadores incluidos para realizar el presente prototipo.Se debería incorporar entre otras mejoras, la posibilidad deestablecer hitos intermedios en la ejecución de losproyectos e introducir la subcontratación como unaalternativa al uso de recursos propios. Además seríainteresante modificar el procedimiento de subasta, paracomprobar el impacto que tiene ciertos aspectos de esteprocedimiento en el funcionamiento global del sistema.Todo ello constituye líneas de investigación en las queactualmente estamos trabajando.

7.- AGRADECIMIENTOSAgradecimientos: Los Ministerios de Educación y

Ciencia y de Ciencia e Innovación han financiado larealización de este trabajo dentro de los proyectosreferencia Ref.: DPI2005-05676 y Ref: TIN2008-06464-C03-02.

8.- BIBLIOGRAFÍA:

- Anavi-Isakow S, Golany B. "Managing multi-project environments through constantwork-in-process". International Journal of ProjectManagement. 2003, Vol.21-1, p.9-18.

- Araúzo JA, Galán JM, López-Paredes A, et al."Multi-agent technology for scheduling andcontrol projects in multi-project environments. AnAuction based approach". IBERAGENTS 08.7thIbero-American Workshop in Multi-AgentSystems. Lisboa: 2008.

- Cabac L. "Multi-agent system: A guidingmetaphor for the organization of softwaredevelopment projects". En: Carbonell JG,Siekman J (eds). Multiagent SystemTechnologies. Lecture Notes in ArtificialIntelligence Vol. 4687. Berlin / Heidelberg:Springer, 2007. p.1-12.

- Clearwater SH. Market-Based Control: AParadigm for Distributed Resource Allocation.River Edge: World Scientific, 1996. 311p. ISBN:981-022254-8

- Cohen I, Mandelbaum A, Shtub A. "Multi-ProjectScheduling and Control: A Process-BasedComparative Study of the Critical ChainMethodology and Some Alternatives". ProjectManagement Journal. 2004, Vol.35, p.39-49.






- Confessore G, Giordani S, Rismondo S. "Amarket-based multi-agent system model fordecentralized multi-project scheduling". Annals ofOperations Research. 2007, Vol.150-1, p.115-135.

- Galán JM, del Olmo R, López-Paredes A."Diffusion of Domestic Water ConservationTechnologies in an ABM-GIS Integrated Model ".En: Corchado E, Abraham A, Pedrycz W (eds).Hybrid Artificial Intelligence Systems. LectureNotes in Artificial Intelligence Vol. 5271. p.567-574. Springer-Verlag, 2008.

- Goldratt EM. Critical Chain. Great Barrington:North River Press, 1997. 246p. ISBN:9780884271536

- Hans EW, Herroelen W, Leus R, et al. "Ahierarchical approach to multi-project planningunder uncertainty". Omega. 2007, Vol.35-5,p.563-577.

- Jennings NR, Wooldridge MJ. "Applying agenttechnology". Applied Artificial Intelligence. 1995,Vol.9-4, p.357-369.

- Kao HP, Wang B, Dong J, et al. "An event-drivenapproach with makespan/cost tradeoff analysis forproject portfolio scheduling". Computers inIndustry. 2006, Vol.57-5, p.379-397.

- Kim K, Paulson J. "Multi-agent distributedcoordination of project schedule changes".Computer-Aided Civil and InfrastructureEngineering. 2003a, Vol.18-6, p.412-425.

- Kim K, Paulson J. "Agent-based compensatorynegotiation methodology to facilitate distributedcoordination of project schedule changes".Journal of Computing in Civil Engineering.2003b, Vol.17-1, p.10-18.

- Kim K, Paulson J, Levitt RE, et al. "Distributedcoordination of project schedule changes usingagent-based compensatory negotiationmethodology". Artificial Intelligence forEngineering Design, Analysis and Manufacturing:AIEDAM. 2003, Vol.17-2, p.115-131.

- Kim K, Paulson J, Petrie J. "Agent-based projectschedule coordination". Computing in Civil andBuilding Engineering. 2000, Vol.1, p.732-739.

- Kumara SRT, Lee YH, Chatterjee K. "Distributedmultiproject resource control: A market-basedapproach". CIRP Annals - ManufacturingTechnology. 2002, Vol.51-1, p.367-370.

- Lee YH, Kumara SRT, Chatterjee K. "Multiagentbased dynamic resource scheduling for distributedmultiple projects using a market mechanism".Journal of Intelligent Manufacturing. 2003,Vol.14-5, p.471-484.

- Lopez-Paredes A, Sauri D, Galan JM. "UrbanWater Management with Artificial Societies ofAgents: The FIRMABAR Simulator".SIMULATION. 2005, Vol.81-3, p.189-199.

- Luh PB, Hoitomt DJ. "Scheduling ofmanufacturing systems using the Lagrangianrelaxation technique". IEEE Transactions onAutomatic Control. 1993, Vol.38-7, p.1066-1079.

- Martínez J, Pérez M, Martínez A. "Laorganización de las oficinas técnicas de proyectosde ingeniería". DYNA Ingeniería e Industria.2001, Vol.76-1, p.7-11.

- Pajares J, Hernandez-Iglesias C, López-ParedesA. "Modelling Learning and R&D in InnovativeEnvironments: a Cognitive Multi-AgentApproach". Journal of Artificial Societies andSocial Simulation. 2004, Vol.7-2.http://jasss.soc.surrey.ac.uk/7/2/7.html.

- Pascual JA, Pajares J, Lopez-Paredes A."Explaining the Statistical Features of the SpanishStock Market from the Bottom-Up". En: Bruun C(ed). Advances in Artificial Economics. TheEconomy as a Complex Dynamic System. LectureNotes in Economics and Mathematical SystemsVol. 584. Springer, 2006.

- Pavón J, Pérez JL. Agentes Software y SistemasMulti-Agente. Madrid: Pearson Educacion, 2005.286p. ISBN: 9788420543673.

- Posada M, López-Paredes A. "How to Choose theBidding Strategy in Continuous Double Auctions:Imitation Versus Take-The-Best Heuristics".Journal of Artificial Societies and SocialSimulation. 2008, Vol.11-1, p.6.http://jasss.soc.surrey.ac.uk/11/1/6.html.

- Wang J, Luh PB, Zhao X, et al. "An optimization-based algorithm for job shop scheduling".Sadhana - Academy Proceedings in EngineeringSciences. 1997, Vol.22-2, p.241-256.

- Wooldridge MJ. An Introduction to MultiagentSystems. New York: John Wiley & Sons, 2002.348p. ISBN: 9780471496915.

- Wu S, Kotak D. Agent-based collaborative projectmanagement system for distributedmanufacturing. IEEE International Conference onSystems, Man and Cybernetics, 2003. Vol.2,p.1223-1228.

- Yan Y, Kuphal T, Bode J. "Application ofmultiagent systems in project management".International Journal of Production Economics.2000, Vol.68-2, p.185-197.

- Zhao X, Luh PB, Wang J. "Surrogate GradientAlgorithm for Lagrangian Relaxation". Journal ofOptimization Theory and Applications. 1999,Vol.100-3, p.699-712.


Documents

José Alberto Araúzo-Araúzo, José Manuel Galán-Ordax ... eficiente de carteras... · Gestión eficiente de carteras de proyectos. ... este modelo, los proyectos demandan parte