Un Enfoque de Sistemas Multiagente para la Gestión Ágil de Riesgos en la Compañía Fractal Mediante la (Re)Planificación de Proyectos

Transcripción

1 Un Enfoque de Sistemas Multiagente para la Gestión Ágil de Riesgos en la Compañía Fractal Mediante la (Re)Planificación de Proyectos Laura Tosselli Departamento Ingeniería en Sistemas de Información UTN FRVM, Argentina Verónica Bogado Departamento Ingeniería en Sistemas de Información UTN FRVM, Argentina Ernesto Martínez INGAR (CONICET UTN) UTN FRSF, Argentina Abstract La (re)planificación de proyectos representa un reto constante en las organizaciones basadas en proyectos, ya que los recursos con los que se cuenta para llevar a cabo las distintas actividades que conforman los planes son limitados y pueden verse afectados por la dinámica y complejidad del contexto en el cual se ejecutan dichos proyectos. Particularmente, en los últimos años, ha cobrado relevancia la gestión de riesgos ocasionados por las relaciones inter-organizacionales, desarrollos tecnológicos, diversidad de recursos, complejidad de productos a desarrollar, etc. Por este motivo, se considera un factor muy importante la correcta (re)asignación de recursos a tareas, de manera inmediata y oportuna, luego de identificado un posible riesgo que podría afectar a un proyecto en particular y, por consiguiente, al portfolio de la organización o de la alianza estratégica entre organizaciones. En el presente trabajo, se propone una arquitectura como base para una solución de tipo Multiagente, siguiendo el mecanismo de aprendizaje por prueba y error y su posterior implementación en un entorno de simulación generativa, donde, a partir de un caso de estudio, se observa la (re)planificación de manera dinámica y en tiempo real de un proyecto frente a la ocurrencia de un riesgo típico en la gestión de proyectos. Palabras claves: (re)planificación de proyectos, Sistema Multiagente, Aprendizaje por Prueba y Error. 1. Introducción El ambiente en el cual se desempeñan actualmente las empresas posee como característica principal un alto nivel de dinamismo e incertidumbre. Una de las causas que provoca dicho fenómeno es la exigencia por parte de los clientes/consumidores en cuanto a restricciones como calidad, tiempo, alcance, etc. En este contexto, es necesario que empresas u organizaciones ofrezcan sus productos y servicios de manera eficiente, por lo que las mismas comienzan a alinearse bajo lo que se denominan alianzas estratégicas, compartiendo proyectos como el diseño de un nuevo producto, el procesamiento de una orden de producción, la realización de una campaña de marketing, etc. [1,2]. A su vez, las organizaciones están migrando su composición estructural desde una forma tradicional a una forma de tipo fractal, donde cada organización se divide en un conjunto de unidades autónomas, descentralizadas y proactivas, encargadas de llevar a cabo sus propios objetivos, los cuales se encuentran alineados con los objetivos generales de la empresa [3]. Particularmente, en este trabajo, se consideran como unidades fractales a los proyectos que se desarrollan dentro de dichas alianzas estratégicas. Debido a la incertidumbre mencionada anteriormente, los proyectos se ven afectados por la ocurrencia de riesgos que pueden ocasionar que los mismos fracasen [4]. Por lo tanto, es imprescindible contar con herramientas que permitan al gestor de proyecto obtener alternativas para realizar la (re)planificación de proyectos en forma ágil y oportuna, para responder dinámicamente frente a dichos eventos que pueden afectar la realización de las diferentes tareas y actividades que componen el proyecto a desarrollar. En este trabajo, se propone un enfoque Multiagente donde cada una de las entidades autónomas que lo componen utiliza una regla de aprendizaje desacoplada denominada Aprendizaje por Prueba y Error [5], siguiendo un objetivo común, el cual consiste en obtener un plan del proyecto a (re)planificar cuya fecha de fin sea minimizada, ante la ocurrencia de un riesgo. El Sistema Multiagente (MAS, de sus siglas en inglés) que conforma la solución planteada se representa a través de distintas vistas arquitectónicas, permitiendo conocer los distintos componentes y sus relaciones. La arquitectura planteada se obtuvo a partir del modelado conceptual tanto del problema como de la solución propuesta, el cual fue presentado en [6]. De esta manera, se pretende agilizar el proceso se (re)planificación ante la ocurrencia de un riesgo mediante la reasignación de las tareas y/o recursos de los diferentes proyectos y subproyectos gracias al proceso de interacción entre varios tipos de agentes, respondiendo de forma inmediata con una solución factible.

2 El trabajo se estructura de la siguiente forma. La Sección 2 describe los fundamentos relacionados a las metodologías y técnicas utilizadas como parte de la solución planteada. La Sección 3 presenta las distintas vistas arquitectónicas relacionadas al entorno Multiagente definido. En la Sección 4, se detallan puntos específicos que se relacionan a la implementación del prototipo desarrollado. En la Sección 5, para ejemplificar la (re)planificación de un proyecto, se introduce un caso de estudio utilizado para la prueba y simulación del prototipo presentado, el cual hace referencia al contexto de industrias farmacéuticas y biotecnológicas. Finalmente, la Sección 6 incluye conclusiones y trabajos futuros. 2. Fundamentos de MAS y Aprendizaje por Prueba y Error Para poder adaptarse al entorno cambiante en el cual se encuentran inmersas, las organizaciones necesitan estructurarse de manera descentralizada, donde la toma de decisiones se realiza de forma rápida y oportuna. Este tipo de estructura, denominada fractal, consiste en un conjunto de unidades que poseen características como pro-actividad y capacidad para tomar decisiones sin depender de una unidad central. Por lo mencionado anteriormente, una organización fractal, o una alianza estratégica formada por organizaciones fractales, pueden ser vistas como un Sistema Multiagente, dentro del cual coexisten entidades autónomas que interactúan para cumplir con un objetivo específico, el cual es compartido por dichas entidades, relacionadas con un entorno, el cual posee un alto grado de incertidumbre, influyendo en las acciones que llevan a cabo los distintos agentes involucrados (Figura 1). MAS Agente Agente Agente Agente Particularmente, un enfoque Multiagente proporciona las siguientes ventajas: (1) mejora de la reactividad ante eventos no planeados; (2) integración dinámica de nuevos agentes o eliminación de algunos de los existentes; (3) operación asíncrona, por lo que los agentes pueden realizar trabajos en paralelo y de esta manera aumentar la velocidad de respuesta; (4) toma de decisiones descentralizada, ya que la misma es llevada a cabo por cada uno de los agentes que componen el Sistema Multiagente [7]; (5) aprendizaje conjunto, con capacidades de razonamiento sobre su base de conocimiento, para generar cursos de acción adaptados al estado particular del proyecto que se está llevando a cabo. El Modelado y Simulación Basado en Agentes (ABMS, de sus siglas en inglés) es un enfoque que está siendo cada vez más utilizado para el estudio de sistemas complejos y para soporte a la toma de decisiones, donde los agentes interactúan a través de las decisiones derivadas por sus políticas de actuación [8, 9]. El desarrollo de la solución Multiagente propuesta requiere que los agentes incorporen capacidades de razonamiento, verificación y aprendizaje similares a las que poseen los seres humanos y que les permitan reaccionar cuando ocurren situaciones imprevistas y complejas, planificar, elegir cursos de acción alternativos cuando el curso normal no está disponible, obtener experiencia de las situaciones que se les presentan, etc. Una de las técnicas de aprendizaje que tiene como característica principal el desacople entre las entidades interactuantes es el mecanismo de Aprendizaje por Prueba y Error. En esta clase de aprendizaje, los agentes interactuantes responden a cambios en sus propias recompensas, las cuales son afectadas indirectamente por las acciones de los demás agentes [5]. La técnica de Aprendizaje por Prueba y Error permite que cada una de las entidades que conforman el Sistema Multiagente pueda obtener la mejor acción a seguir en cada instante de tiempo mediante una implementación simple (Figura 2), donde el estado de cada uno de los agentes interactuantes (z i ) se compone de un estado de ánimo o mood (content, discontent, hopeful, watchful), una acción de referencia (ā i ) y una recompensa de referencia (ū i ). A partir del estado de ánimo, y en base a las recompensas obtenidas, cada agente determina su próxima acción a seguir [5]. La forma en la que se realizan los cambios de estado se muestra en la Figura 2. Entorno Figura 1. Sistema Multiagente, según Aprendizaje por Prueba y Error

3 Figura 2. Cambios de estado de agentes a partir de su estado actual [5]. En la literatura, se han propuesto varios trabajos relacionados con la (re)planificación de órdenes de producción en entornos industriales, donde la aplicación de un enfoque Multiagente ha resultado exitoso, como por ejemplo en [10,11]. En [12], se plantea la organización o red de organizaciones como un Sistema Multiagente para la planificación de proyectos, haciendo uso del aprendizaje por refuerzos (RL, de sus siglas en inglés), y en [13], se presenta la planificación del portfolio de proyectos de una organización utilizando un Sistema Multiagente, donde los agentes interactuantes deciden qué proyectos planificar y cuales rechazar, teniendo en cuenta los costos de dichos proyectos. En este trabajo, se pretende ampliar esa visión logrando la (re)planificación de proyectos del portfolio completo de la organización o alianza estratégica, focalizando en el tratamiento de riesgos que afectan a las distintas actividades que conforman el/los proyecto/s. 3. Arquitectura del Sistema Multiagente para (Re)Planificación de Proyectos Un enfoque de agentes situados es requerido para producir comportamiento coherente, robusto y en un dominio impredecible y complejo de tal manera que sus objetivos se logran de acuerdo a algunos criterios de evaluación. La arquitectura debe permitir a los agentes detectar aquellos eventos que pueden alterar sus planes, como son cambios en los requerimientos u ocurrencia de riesgos en el logro de las resultantes esperadas de un proyecto [14]. La arquitectura seleccionada para la implementación del Sistema Multiagente propuesto es necesariamente de tipo reactiva, ya que no se posee un modelo acabado del entorno en el cual se encuentra inserto dicho sistema y, por el contrario, los agentes interactuantes deben tomar decisiones en un entorno impredecible y altamente cambiante [14], como ocurre en el caso de la (re)planificación de proyectos. En este tipo de enfoque, el comportamiento inteligente emergerá en un sistema complejo, donde se manejan jerarquías de acciones que dependen de ciertas abstracciones capturadas del entorno, el cual es afectado además por las acciones que los demás agentes produzcan en él. En este tipo de arquitecturas, cada agente actúa siguiendo un modelo Pavloviano del tipo estímulo-respuesta, donde su comportamiento se fundamenta en interacciones o situaciones elementales [7, 14]. Siguiendo el enfoque Multiagente, se especifican a continuación dos vistas de la arquitectura Vista Estática La separación en capas de los diferentes conceptos de dominio necesarios para dar solución a la (re)planificación de proyectos dentro de una organización o alianza estratégica, permite obtener un alto grado de flexibilidad, mantenimiento, reusabilidad y portabilidad. En este contexto, y al incluir el concepto de fractal tomando al proyecto como unidad, se definieron las capas: Negocio, Especificación, Evaluación, Tratamiento y Comunicación (Figura 3). Para la definición de las capas, se siguió el enfoque GQM (goal-question-metrics) [15, 16], el cual permite definir operacionalmente los objetivos globales, de manera que los agentes se guíen por indicadores cualitativos y cuantitativos. La Capa de Negocio incluye aquellos conceptos y relaciones del contexto y los objetivos a nivel estratégico de cada proyecto desarrollado dentro de la organización o alianza estratégica. La Capa de Especificación define operacionalmente los objetivos y restricciones del contexto mediante el planteo de requerimientos y riesgos relacionados a cada proyecto a (re)planificar. Además, incluye, para cada requerimiento u ocurrencia de riesgos un plan de acción o respuesta predefinido, el cual debe ser insertado dentro del plan de proyecto general. Esta capa reúne la información relacionada con métricas e indicadores que permiten definir valores de referencia de requerimientos y riesgos, los cuales luego serán comparados con las medidas obtenidas a partir de estos requerimientos en la Capa de Evaluación. La Capa de Evaluación reúne la información de las medidas realizadas en los requerimientos y sus cambios. En cuanto a riesgos, esta capa captura la información necesaria para realizar un análisis tanto cualitativo como cuantitativo de los eventos riesgosos, lo cual permite priorizar según su impacto en el proyecto, teniendo en cuenta cálculos de variables tales como probabilidad de

4 ocurrencia, impacto y valor esperado para cada riesgo identificado. La Capa de Tratamiento captura información relacionada con el plan del proyecto, en términos de tareas y recursos, además de contener los módulos correspondientes a los agentes y el conocimiento que dichos agentes necesitan para ejecutar la (re)planificación del/los proyecto/s. Esta capa es definida transversalmente porque utiliza las demás capas para alcanzar su objetivo. Utiliza la Capa del Negocio para evaluar que los cambios que puedan incorporarse en el plan de proyecto sean consistentes con los objetivos definidos para este proyecto. Además, utiliza la Capa de Especificación para obtener los planes de acción o respuesta para la (re)planificación. Finalmente, la Capa de Evaluación se utiliza para monitorear y controlar los cambios en requerimientos y riesgos. En esta capa, se incluye: (1) Aprendizaje, el cual proviene del estímulo-respuesta con el entorno; (2) Librería de Acciones, la cual constituye un conjunto de acciones que cada agente puede ejecutar en base a lo que percibe y la evaluación del efecto de los eventos que generan riesgos. Por último, se propone una Capa de Comunicación. Esta capa contiene los protocolos para el intercambio de mensajes entre los agentes, y entre los agentes y el entorno en el cual se desenvuelven. Negocio Tratamiento Comunicacion Contexto Objetivos Especificacion Acciones Requerimientos Riesgos Protocolos Evaluacion Aprendizaje Indicadores Medidas Figura 3. Vista Estática de la Arquitectura de la Solución Planteada Vista Dinámica Para comprender la interacción entre los distintos componentes que conforman el Sistema Multiagente planteado como solución para la (re)planificación de proyectos, se desarrolló una vista dinámica de la arquitectura, como se muestra en la Figura 4. En la imagen, se considera la interacción entre un agente GestorTarea y un agente GestorRecurso, donde cada uno puede instanciarse según las tareas (fases, actividades, etapas, etc.) y recursos que existan por cada proyecto. Estos agentes interactúan para lograr cada uno de los planes opcionales (RepositorioPlanes). Asimismo, se define un GestorProyecto por cada proyecto (o subproyecto, o programa), cuyas acciones colaboran en la planificación del proyecto superior, en el cual el proyecto gestionado es subproyecto. Las características particulares de cada uno de los agentes propuestos se detallan en las tablas: Tabla 1, Tabla 2 y Tabla 3 respectivamente. El proceso de (re)planificación de un proyecto se puede representar como un juego repetitivo entre los agentes interactuantes, considerados del tipo selfinterested, utilizando mecanismos de negociación multilaterales (subastas), donde no existe la necesidad de contar con una autoridad mediadora [14]. Los tipos de

5 agentes definidos en esta propuesta son: agente GestorProyecto, agente GestorTarea y agente GestorRecurso, cuyos objetivos se encuentran alineados (Teoría de Juego Cooperativa [14]) para obtener la mejor estrategia de (re)planificación de un proyecto compartido por las organizaciones que conforman una alianza estratégica. «call-return» «dataaccesor» GestorTarea «call-return» GestorRecurso «dataaccesor» GestorProyecto «data repository» RepositorioPlanes Plan Opcional 1 «write» Asignación1... Asignación n «read» Plan Opcional 2 Asignación 1... Asignación n Figura 4. Vista dinámica de la Arquitectura del Sistema Multiagente propuesto. Tabla 1. Características del GestorTarea Tabla 2. Características del GestorRecurso Agente GestorTarea Agente GestorRecurso Meta Minimizar su tiempo de ejecución. Meta Maximizar su tiempo de ocupación Estrategia Seleccionar el mejor recurso (mayor capacidad) para su procesamiento. Estrategia Seleccionar combinación de tareas que maximizan su tiempo de ocupación. Conocimiento Recursos permitidos; tiempo de inicio; tiempo de fin; necesidad de procesamiento. Conocimiento Capacidad de Procesamiento Acciones Simple: Uno de los recursos que puede procesarla. -Enviar solicitud -Calcular sus nuevos parámetros. Acciones Compuesta: Tareas a procesar en una iteración (stage). -Aceptar /rechazar solicitud. Mensajes Solicitud de Procesamiento Mensajes Respuesta de aceptación/rechazo.

6 Tabla 3. Características de Gestor Proyecto Meta Estrategia Conocimiento Acciones Mensajes Agente Gestor Proyecto Minimizar el tiempo de desarrollo del proyecto. Obtener mejor asignación de recursos a tareas, dentro del tiempo limite de finalización del proyecto (deadline). Tiempo límite de finalización del proyecto. Compuesta: Combinación de asignaciones de recursos a tareas. Seleccionar estrategias. Solicitud de (re)planificación Los agentes mencionados anteriormente son parte de un juego estratégico. A medida que transcurre la iteración (stage), se juegan distintas subastas entre los Gestores de Tareas que representan a las tareas a (re) planificar y los Gestores de Recursos disponibles para llevarlas a cabo. Como resultado de cada una de estas subastas, se establecen contratos entre tareas-recursos que definen la asignación de un recurso a una tarea, dando como resultado un plan para cada iteración. Luego de ejecutadas las distintas iteraciones (definidas por el usuario), el GestorProyecto debe decidir, de acuerdo a su estado de ánimo e índice de exploración/explotación, si elige como nueva acción a ejecutar uno de los planes opcionales obtenidos en alguna de las iteraciones, como se muestra en la Figura 4, o si sigue ejecutando la misma acción de referencia que obtuvo en iteraciones anteriores. Los valores de inicialización del estado de cada agente son los siguientes: discontent, sin acción de referencia, sin recompensa de referencia. El proceso de selección en cada iteración (stage) del juego se describe de la siguiente manera, esquematizándose en la Figura 5: 1) Cada agente GestorTarea que representa a una de las tareas que van a ser (re)planificadas establece un enlace con los agentes GestorRecurso a contratar (en este caso, cada tarea envía solicitud de contrato a uno de los recursos permitidos para su procesamiento, seleccionando de acuerdo al estado de ánimo que posee el GestorTarea, a la capacidad de procesamiento de los recursos y al índice de exploración-explotación definido para su tipo). Se considera también que las tareas que poseen predecesoras, comienzan a participar en el proceso de selección una vez que su/s predecesora/s ya se encuentra asignada/s a algún recurso. 2) Cada agente GestorRecurso recibe las peticiones realizadas por los agentes GestorTarea que los solicitan, y selecciona de acuerdo a su estado de ánimo, y al índice de exploración-explotación definido para su tipo. Por lo tanto, un GestorRecurso tiene por objetivo maximizar su tiempo de ocupación, es decir que las tareas aprovechen al máximo su capacidad de procesamiento. Si el agente GestorRecurso debe implementar su acción de referencia (de acuerdo a su índice de exploración/explotación) para cada tarea que le solicite servicio de procesamiento, evaluará si dicha tarea se encuentra dentro de su acción de referencia. Si es así, el recurso elegirá entre las tareas que pertenecen a su acción de referencia; de lo contrario, el GestorRecurso no participará de la subasta en curso. 3) Este proceso se repite hasta que no existan tareas sin asignaciones obteniendo un plan (conjunto de asignaciones de recursos a tareas). Se realizan varias iteraciones (stages) del mismo juego, donde por cada una de ellas se obtiene un plan. 4) Terminadas dichas iteraciones, el GestorProyecto es quien determina, según su estado de ánimo y el índice de exploración-explotación definido para su tipo, el plan que más se ajusta a su objetivo, el cual apunta a minimizar el tiempo de desarrollo del proyecto completo. Si el GestorProyecto no tiene una acción de referencia, se le asigna aleatoriamente una acción (la cual consiste en uno de los planes opcionales obtenidos de la interacción entre Gestores de Tareas y Gestores de Recursos) y dicha acción pasa a ser su acción de referencia para el próximo juego. De lo contrario, si el GestorProyecto ya posee una acción de referencia, se compara la recompensa de referencia con la nueva recompensa obtenida y si la nueva recompensa es mayor, pasa a ser su recompensa de referencia, al igual que la nueva acción jugada (plan seleccionado). 4. Implementación En el presente trabajo, el objetivo del sistema propuesto consiste en la (re)planificación de proyectos que surge a partir de la ocurrencia de riesgos que ocurren en el entorno en el cual se encuentra inmersa la organización que lleva a cabo el proyecto, y que afectan su planificación inicial, buscando como meta u objetivo final minimizar el tiempo de desarrollo de o los proyectos dentro del portfolio de la organización o red de organizaciones. La arquitectura propuesta se implementó en un prototipo utilizando NetLogo, el cual es un entorno Multiagente de modelos simulados que permiten generar comportamientos emergentes resultantes de las interacciones entre agentes situados. NetLogo es apropiado para modelar sistemas complejos en desarrollo en el tiempo.

7 Figura 5. Interacción entre Agentes dentro de la Solución Planteada.

8 NetLogo permite dar instrucciones a cientos o miles de agentes todos operando autónomamente. Esto hace que sea posible explorar la relación entre el comportamiento micro-nivel de los individuos y los patrones de nivel macro que surgen de su interacción [17]. La razón por la cual se seleccionó este entorno de simulación para crear el modelo que permita la (re)planificación de proyectos se debe a que el mismo permite el comportamiento asíncrono de múltiples agentes, a partir de un lenguaje relativamente simple. En esta primera implementación se considera la (re)planificación de proyectos, dentro de los cuales existen un conjunto de recursos que pueden procesar a un conjunto de tareas, entre las cuales existen relaciones de precedencia (Figura 6). En el prototipo desarrollado, se definieron controles para el ingreso de datos por parte del usuario, como la cantidad de planes opcionales a obtener de la interacción entre tareas y recursos, trade-off de exploración y explotación tanto de Gestores de Tareas como Gestores de Recursos, capacidades de procesamiento de los recursos que intervienen en el proyecto, determinación de holgura con respecto a la fecha de finalización del proyecto considerado como el tiempo adicional que el cliente del proyecto está dispuesto a esperar, etc. (Figura 6). Las distintas tareas que conforman el proyecto, junto con sus relaciones de precedencia son tomadas como entrada para el Sistema Multiagente, donde cada tarea es representada por un agente GestorTarea y cada recurso por un agente GestorRecurso. A su vez, cada tarea es dividida en unidades de tiempo, definiendo su duración en el proyecto. Por último, cada proyecto se representa a través de un agente GestorProyecto, encargado de seleccionar uno de los planes opcionales que cumpla con el objetivo global del sistema, el cual consiste en encontrar un plan cuya fecha de finalización se encuentre dentro de los límites definidos por el administrador de proyectos involucrado o por las organizaciones participantes en el proyecto que se está (re)planificando. Siguiendo la secuencia definida en la sección anterior, los agentes Gestores de Tareas y Gestores de Recursos interactúan mediante mecanismos de subastas para obtener distintos planes opcionales de proyecto, con la correspondiente asignación de recursos a las tareas. Al momento de la obtención de un posible plan, se verifica que el mismo no haya sido obtenido anteriormente y que se encuentre dentro del límite de finalización definido para el proyecto (deadline). Obtenidos los distintos planes opcionales, el GestorProyecto selecciona aleatoriamente uno de dichos resultados y se comienza con la simulación. Figura 6. Tareas del proyecto a (re) planificar y relaciones de precedencias entre las mismas. Una vez comenzado el proceso de simulación, el usuario puede incorporar el tipo de riesgo permitido, el cual consiste en disminuir la capacidad de procesamiento de uno de los recursos. A partir de la incorporación del riesgo, se comienza la (re)planificación del plan seleccionado por el GestorProyecto, donde tareas que aún no comenzaron, interactúan con los recursos para obtener nuevas asignaciones, según los mecanismos

9 detallados anteriormente. Una vez terminada la simulación, el GestorProyecto, obtiene un plan que contempla el riesgo que afecta al proyecto (re)planificado. 5. Caso de Estudio El ejemplo que se presenta a continuación corresponde a un proyecto dentro de la industria farmacéutica, particularmente al desarrollo de un nuevo fármaco. En la Figura 7, se muestran las distintas tareas a llevar a cabo para completar el proceso de desarrollo de una nueva droga. Dicho proyecto es llevado a cabo por varias compañías que conforman una alianza estratégica. En base a las etapas del proceso de desarrollo de una nueva droga presentado en la Figura 8 [6], se definió un proyecto dividido en dos subproyectos, constando de un número finito de tareas, con su duración, y recursos, constituyendo la entrada al Sistema Multiagente propuesto. Además, se establece como restricción que un recurso solamente puede procesar una tarea por vez, considerando a este último punto como una restricción clasificada como restricción dura. En trabajos futuros se implementará el caso de estudio sin tener en cuenta esta restricción. Además, se (re) planifica a partir de un solo tipo de riesgo que puede ocurrir en el entorno del proyecto, que consiste en la disminución de la capacidad de un único recurso en un instante de tiempo determinado. A partir de dicha entrada, el MAS comienza con el proceso de planificación del proyecto, obteniendo los distintos planes opcionales, conformados por las asignaciones entre tareas y recursos, como se muestra en la Figura 9. Figura 8. Proceso de Desarrollo de Nuevo Fármaco [6] Figura 7. Tareas Proceso de Desarrollo Nuevo Fármaco.

10 (a) (b) Figura 9. (a) Plan opcional con asignación completa. (b) Plan opcional con asignación incompleta. En la Figura 9 (a), se obtuvo un plan opcional donde todas las tareas consiguieron establecer un compromiso de procesamiento con alguno de los recursos permitidos, antes de la fecha considerada como fecha límite de finalización del proyecto (teniendo en cuenta el tiempo de holgura definido por el usuario a través de la interfaz), mientras que en la Figura 9 (b) existen tareas que no lograron obtener dicho compromiso antes de la fecha estipulada, por lo que el plan no es considerado como plan opcional para ser seleccionado por el agente GestorProyecto. Una vez obtenidos los posibles planes, debido a una estabilización de interacciones entre tareas y recursos, el agente GestorProyecto selecciona aleatoriamente uno de dichos planes y comienza la simulación del mismo. A partir del momento en que comienza a transcurrir el tiempo de simulación, el usuario puede disminuir la capacidad de procesamiento de alguno de los recursos involucrados en el plan de proyecto, simulando de esta manera la ocurrencia de un riesgo que provocará la (re)planificación del plan seleccionado. En el ejemplo mostrado, se disminuye la capacidad de procesamiento del Recurso 2, pasando de 50 a 20. En el instante de tiempo en el que se introduce el riesgo al sistema, el gestor de proyecto envía un mensaje de (re)planificación a aquellas tareas cuyo tiempo de comienzo sea mayor al instante en el cual se introdujo el riesgo, ya que las tareas que se encuentran en ejecución no serán (re)planificadas. Como resultado de ese proceso de (re)planificación del plan seleccionado, respetando el tiempo de finalización del proyecto más la holgura de tiempo definido por el usuario, se obtiene un nuevo plan, con diferentes asignaciones de recursos a tareas y diferente tiempo estimado de finalización, pasando de 33 a 35 unidades de tiempo, como se muestra en la Figura 10. El agente GestorProyecto, basado en su estado (donde se considera su estado de ánimo y la recompensa obtenida por el plan seleccionado), considera si es necesario simular otro plan opcional o terminar el proceso de búsqueda.

11 Figura 10. Plan obtenido a partir de la (re)planificación incorporando el riesgo ingresado por el usuario Discusión Por lo mencionado anteriormente, a la complejidad del problema de (re)planificación se suma la complejidad de la gestión de los riesgos [4]. En este contexto, una solución que permita dinámicamente analizar nuevos planes ante la necesidad de (re)planificar debido a que un recurso no se encuentra disponible más para el proyecto, o existen tareas que se deben agregar debido a la complejidad del producto que se está desarrollando, o a la complejidad tecnológica que ocasiona retrasos, entre un sin número de riesgos que pueden ocasionar desvíos en los proyectos, permitiría a los administradores de proyectos poder analizar escenarios posibles antes de tomar decisiones. En la actualidad, existen propuestas relacionadas al presente trabajo en cuanto a la problemática a abordar, a la tecnología, mecanismos y herramientas utilizadas para su desarrollo, etc. En lo que se refiere a la problemática de planificación de proyectos utilizando un Sistema Multiagente, existen trabajos formulados como en [18, 19, 20], que presentan una solución para la planificación de n proyectos al igual que la presente propuesta, pero se diferencian por el tipo de arquitectura de agentes utilizada, las cuales hacen más difícil o imposible la (re)planificación en tiempo real y autónoma a partir de mecanismos de aprendizaje, aspecto que se implementa en esta propuesta a través de la regla de Aprendizaje por Prueba y Error, que junto a la simulación generativa permite analizar tempranamente diferentes escenarios de (re)planificación ante la ocurrencia de un evento imprevisto sin tener que ejecutar el proyecto previamente para tener un panorama general. Adicionalmente, los trabajos relacionados analizados no se enfocan en una de las áreas más sensibles e importantes dentro de la Gestión de Proyectos, como lo es la Gestión de Riesgos, en donde es necesario automatizar la (re)planificación de proyectos incorporando los riesgos utilizando técnicas que no dependan solamente de juicios de expertos o técnicas informales [21]. La propuesta actual tiende a abarcar no solo la gestión de tareas y recursos, sino también la gestión de riesgos y requerimientos, obteniendo una solución integral ante el problema de la (re)planificación del/los proyecto/s. Si bien, entre las limitaciones presentes en este enfoque, se puede mencionar la necesidad de información de entrada para ejecutar la simulación, dicha información es normalmente registrada en cualquier organización, es decir, no se requieren de detalles específicos de cada proyecto, lo cual lo hace aplicable a pequeñas y medianas empresas. 6. Conclusiones y Trabajos Futuros La Gestión de Proyectos, particularmente la (re)planificación, es un problema complejo de ser tratado, ya que las organizaciones y sus relaciones así como las necesidades del manejo de recursos y los productos cada vez más sofisticados que requieren de trabajo específico (incluyendo tareas, fases, actividades, etc.), generan un contexto de incertidumbre y dinamismo cada vez mayor. A su vez, se incorpora a este contexto la Gestión de Riesgos, la cual debe administrar aquellos eventos cuya ocurrencia puede afectar a la proyección futura y estabilidad de una organización o alianza estratégica. Así, el generar herramientas que permitan manejar estas particularidades en forma dinámica y en tiempo real, es de gran ayuda a los administradores de proyectos en cualquier tipo de industria. Un enfoque Multiagente tiene como ventaja principal responder de manera rápida y oportuna frente a situaciones imprevistas provenientes del entorno en el cual interactúan los agentes, en este caso, debido a la ocurrencia de riesgos que pueden requerir la (re)planificación de proyectos. Mediante la implementación de la arquitectura desarrollada y su posterior simulación, el administrador de proyectos cuenta con una herramienta que da soporte ágil tanto para la planificación inicial de un proyecto como para la (re)planificación del mismo luego de la

12 ocurrencia de un riesgo (en este caso, la disminución en la capacidad de un recurso), lo cual se considera de vital importancia para una industria creciente, para poder adaptarse al entorno cambiante que se desarrolla tanto dentro como fuera de la organización o alianza estratégica. Como trabajo futuro, se propone la formalización del comportamiento de los agentes interactuantes que conforman el Sistema Multiagente y su entorno con el fin de automatizar aún más el proceso de gestión de proyectos en las organizaciones fractales basadas en proyectos. Además, se pretende ampliar el prototipo desarrollado para lograr la (re)planificación de varios proyectos compartidos por las organizaciones que componen una alianza estratégica, donde existen recursos compartidos y conflictos que surgen por la ocurrencia de riesgos y cambios en requerimientos, profundizando en el análisis y evaluación de los mismos. 7. Referencias [1] Canavesio, M. Un modelo de compañía fractal para la integración entre empresas usando proyectos. Tesis Doctoral. Universidad Tecnológica Nacional, Santa Fe, Argentina, [2] Canavesio, M., Martinez, E. Enterprise modeling of a project-oriented fractal company for SMEs networking. Computers in Industry, Vol. 54, 2007, pp [3] Warnecke, H.J. The Fractal Company: A Revolution in Corporate Culture. Berlin: Springer-Verlag. ISBN: , [4] PMI. Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK). Project Management Institute, 4ª edición. ISBN , [5] Young, H. P. Learning by trial and error. Games and Economic Behavior, 2009, pp [6] Tosselli, L., Bogado, V., Martínez, E. Un Enfoque Integrado para la Gestión de Riesgos y Cambios en la (Re)Planificación de Proyectos en Organizaciones Fractales. Conaiisi Congreso Nacional de Ingeniería Informática/Sistemas de Información. San Luis, Argentina, [7] Vlassis, N. A Concise Introduction to Multiagent Systems and Distributed Artificial Intelligence. Amsterdam: Morgan y Claypool. ISBN: , [8] Epstein, J. M. Generative social science. Studies in agentbased computational modeling. Princeton University Press. ISBN: , [9] Railsback, S., Grimm, V. Agent-Based and Individual- Based Modeling: A practical Introduction. Princeton UniversityPress. ISBN: , [10] Martínez, F., Aguilar, J., Bravo, C. Sistema Multiagente para la Planificación de la Producción en Automatización. XIII Congreso Latinoamericano de Control Automático / VI Congreso Venezolano de Automatización y Control, [11] Zuobao, W., Weng, M. Multiagent Scheduling Method with Earliness and Tardiness Objectives in Flexible Job Shops. IEEE Transactions on Systems, Man, and Cybernetics Part B: Cybernetics, vol. 35, N 2, [12] Canavesio, M., Martínez, E. Los agentes de la compañía fractal aprenden a seleccionar los socios con quienes establecer relaciones cliente-servidor. CACIC XVII Congreso Argentino de Ciencias de la Computación, [13] Araúzo, J., Pajares, J., Lopez-Paredes, A. Gestión eficiente de carteras de proyectos. Dyna Ingeniería e Industria, vol. 84 (9), 2009, pp ISSN [14] Wooldridge, M. Introduction to MultiAgent Systems. 2 Edición. John Wiley & Sons, Chichester ISBN-13: , [15] Asnar, Y., Giorgini, P., Mylopoulos, J. Goal-driven risk assessment in requirements engineering. Requirements Eng., Vol. 16, 2011, pp [16] Islam, S., Mouratidis, H. Weippl, E. An empirical study on the implementation and evaluation of a goal-driven software development risk management model. Information and Software Technology, Vol. 56, 2014, pp [17] Vidal, J. Fundamentals of Multiagent Systems with NetLogo Examples. Disponible en: Multiagent-Systems, último acceso 15/08/2015]. [18] Bodea, C., Badea, I., Mogos, R. A Multi-Agent System with Application in Project Scheduling. Management & Marketing. Challenges for the Knowledge Society, Vol. 6, No. 4, 2011, pp [19] Adhau, S., Mittal, M., Mittal, A. A multi-agent system for distributed multi-project scheduling: An auction-based negotiation approach. Engineering Applications of Artificial Intelligence, Vol. 25, 2012, pp [20] Bodea, C., Badea, I., Purnus, A. Complex Project Scheduling using Multi-Agent Methods: A Case Study for Research Projects. Management & Marketing. Challenges for the Knowledge Society, Vol. 5, No. 3, 2010, pp [21] McNeil, A., Frey, R., Embrechts, P. Quantitative Risk Management. Princeton University Press. Princeton and Oxford. ISBN: , 2005.