Ax2012, AIF Services

Tras una segunda lectura del libro "Microsoft Dynamics Ax 2012 Services" publicado por Pack Publishing, voy a tratar de sintetizar los concepto clave y conclusiones que extraigo.

Microsoft ha realizado un esfuerzo grande para que Ax proporcione los medios, más que suficientes, para que el sistema sea conectable con cualquier otro sistema. Para ello, el servidor de aplicaciones (AOS) se ha convertido en un host WCF (Windows Communication Foundation, concebida para permitir una programación rápida de sistemas distribuidos y el desarrollo de aplicaciones basadas en arquitecturas orientadas a servicios, SOA)

Las ventajas que ello trae son:

1. Podemos diseñar y programar nuestros servicios en X++, reutilizando la lógica que ya tenemos!
2. No necesitamos IIS, si nos limitamos al ámbito de la red local
3. Posibilita el uso de todos sus protocolos, tanto los síncronos y asíncronos (NetTcp, HTTP, FileSystem, MSMQ)
4. Poblemos emplear IIS para servicios expuestos fuera de nuestra red local, y la comunicación entre IIS y AOS ya no se realizará mediante Business Connector sino como WCF Routing.
5. Podemos publicar servicios básicos (netTcp) de una forma sencilla

Veamos gráficamente y fundamentalmente lo que ofrece:

Como podemos ver hay varios tipos de servicios, vamos a entrar en detalle en cada uno de ellos y sobre todo en cuál es su utilidad y cuando deben ser utilizados.

Document services
Permiten exponer un documento (una o varias tablas) y realizar operaciones CRUD sobre el mismo. Su desarrollo es más laborioso, requiere definir una query, unas tablas (Axd) y una clase para el documento y otra para el servicio. Las operaciones CRUD se simplifican ya que en la tabla Axd podemos incluir la lógica de acceso a datos y sus validaciones.
Es recomendado para servicios complejos y que deriven en operaciones con datos, aunque hemos de tener cuidado con los cambios en el esquema de datos de las tablas que se emplean, ya que pueden alterar el servicio.

Custom services
Se desarrollan en base a una clase de contrato (service contract) que contendrá la lógica y un conjunto de clases de datos (data contract) que definirán los parámetros de entrada y salida.
Son recomendables para servicios menos complejos, servicios de proceso y no tanto orientados a datos. Son más sencillos y flexibles a la hora de desarrollar, no seremos dependientes del modelo de datos e incluso podemos llegar a reutilizar los data contract entre diversos servicios.
El nuevo marco de SysOperation será ideal para que reutilicemos la lógica de proceso para clientes Ax como para sus servicios, debemos orientar nuestros desarrollos a ese nuevo marco e ir discontinuando el uso de RunBase.

System services
Estos servicios son proporcionados out-of-the-box, por lo tanto están a nuestra disposición para ser consumidos desde soluciones externas. Tenemos a disposición:

• Query service: Facilita consultar información de tablas y campos Ax, pero no de métodos, por lo tanto no podemos obtener datos calculados y re aprovechar esa lógica. Los datos son devueltos en un DataSet. Ese acceso puede hacerse utilizando:

1. Una query ya definida en el AOT
2. Una query definida al vuelo mediante la clase QueryMetadaClass
3. Una query dinamica definida como clase extendida de AIFQueryBuilder

• Metadata service: Permite acceder a información de los metadatos de objetos de AOT. Por ejemplo obtener el nombre de las tablas, propiedades, etc.
• Session service: Nos proporcionará información de la sesión por la que estamos realizando la conexión. Podremos consultar el usuario, idioma, empresa, etc.

Interoperabilidad, no negociable

Hoy en día, en cualquier organización medianamente compleja es raro encontrar que el sistema de información se limite a una única solución, por buena y completa que sea. Es normal tener que lidiar con:

• Sistemas anteriores (legacy systems)
• Soluciones de nicho o especializadas, incluso diseñadas y desarrolladas in-house
• Soluciones integradas con maquinaria o línea de logística

Además de esto, es posible que incluso teniendo una buena solución core e incluso ampliable, como Microsoft Dynamics Ax, sea conveniente desarrollar o integrar soluciones satélites, en vez de desarrollarlas dentro del sistema. Esta decisión de arquitectura puede fundamentarse fácilmente en:

• La tecnología a emplear. Puede ser más fácil / rápido / barato hacer cierto tipo de soluciones en plataformas distintas a la proporcionada por el sistema core.
• La ubicación y dispositivo del usuario. Si el usuario trabaja de forma remota, quizás una solución 3 capas con trabajo semi-desconectado sea más conveniente y eficiente. Por otro lado si el usuario no usa sistemas compatibles con nuestro core, no tendremos más remedio que realizar una solución externa. Se podría alegar que con soluciones de tipo Terminal, como Escritorio remoto o Citrix, se podría paliar también el problema, aunque de una forma poco amigable para el usuario.
• Los costes de licenciamiento y mantenimiento. Tampoco hemos de descuidar los costes asociados. Si tenemos cientos de usuarios que realizan tareas puntuales o acceden a información limitada, seguramente nos será más económico una solución externa pero bien relacionada con nuestro core, que la adquisición de esos cientos de licencias.

Por todo lo anterior, la interoperabilidad no es un concepto negociable. Gracias a ella, y con un diseño racional, podremos disponer de un sistema capaz de entenderse y hacerse entender con otros, evitándonos por tanto tener que reescribir lógica de negocio o duplicar datos en distintos sistemas.

Puede haber distintos grados de interoperabilidad, como por ejemplo:

1. Nivel 0. No es posible acceder al sistema ni a su información más que desde el propio sistema. Si te encuentras un sistema así y tienes que integrarlo, prepárate a remangarte, tener ideas muy imaginativas y sudar...no me gustaría estar en tu pellejo!
2. Nivel de datos. Somos capaces de acceder a la información, pero no a la lógica del sistema. Es un primer paso, podremos leer e introducir información, aunque las cautelas deben ser máximas ya que al hacerlo de forma externa podemos estar saltándonos las reglas de negocio de la solución y trabajar con información no coherente.
3. Nivel de librería. Disponemos de una API, DLL o similar que nos facilita el acceso a la lógica. Aquí las dificultades vienen cuando librería no ofrece toda la lógica que necesitamos, o bien la librería no corre sobre la plataforma que necesitamos que corra.
4. Nivel de servicio. Realmente este nivel es muy similar al anterior, salvo la limitación de plataforma. Los servicios están basados en estándares y por tanto debe ser operables desde distintas plataformas. La limitación que podemos seguir teniendo es la de que los servicios expuestos no cubran el 100% de nuestras necesidades.
5. Nivel de servicio extensible. Parte de la anterior, pero además el sistema ofrece la posibilidad de extender los servicios ofrecidos, eliminando por tanto la limitación anterior y haciendo por tanto que este caso sea perfecto de cara a la interoperabilidad.

Comentar, por clarificar, que los niveles anteriores no son excluyentes, y por tanto cuantos más y más altos cumpla nuestro sistema mejor será para comunicarse con posibles "vecinos" que conformen nuestro universo de soluciones empresariales.

Breves reflexiones: Grandes y rápidos

“De un tiempo a esta parte llego siempre tarde, a todas mis citas, y la vida me parece una fiesta a la que nadie se ha molestado en invitarme” (Canción: "Últimamente" de Ismael Serrano)

He querido empezar este artículo con dicha estrofa ya que refleja cómo evoluciona este mundo. Por un lado, gracias a los avances y la tecnología de esta era digital, se incrementa la velocidad, todo fluye y discurre sin pausa, a un ritmo difícil de seguir. Como ejemplo, hoy la humanidad es capaz de:

• Generar información y enviarla instantáneamente a cualquier lugar del planeta. Igualmente recibir y consumir esta información, incluso sin demandarla
• Mover casi cualquier producto de un punto a otro del planeta en 2-3 días

Y por otro lado, la estrofa refleja un posible sentimiento de una parte de la población o negocios, a los que esta revolución puede dejar fuera de juego.

Por lo tanto, estamos ante una globalización que avanza rápidamente y sin mirar hacia atrás. A pesar de este peligro, personalmente opino que es un movimiento positivo, enriquecedor. Además, estoy seguro que seremos capaces de adaptarnos y ese riesgo finalmente quedará minimizado.

¿Cómo tener éxito en un mundo así? Yo sólo veo dos maneras, una ser grande y otra ser rápido. Ambas cosas a la vez sería lo ideal, pero es muy muy difícil.

Grande

Ser grande implica poder estar presente y operar en varios mercados, incluso con múltiples propuestas de valor. Es decir, aprovechar la globalización y las economías de escala. De esta manera el riesgo de exclusión se minimiza, podemos soportar la caída de un cliente, mercado o producto, seguramente se verá compensado por el crecimiento en otro.

A pesar de todo esto, el grande no debe quedarse de brazos cruzados, pues si lo hace, parte de su tarta se la irán comiendo los rápidos, y algunos de estos pueden hacerse grandes e incluso dejarles pequeños. Por lo tanto, el grande debe tratar de continuar creciendo, y no bajar el ritmo, es decir, como mínimo no ser lento.

Rápido

Es aquel que es capaz de aprovechar una oportunidad, sin dudarlo, sin pestañear, detecta (o crea, siendo innovador) y satisface una demanda en tiempo record. Si esa demanda es global, rápidamente se hará grande, o se atragantará y morirá de éxito. Si es una demanda local, debe tratar de adaptar su propuesta de valor para abrirse a más clientes y mercados, o bien buscar y satisfacer otras demandas, o bien asociarse con otros rápidos para tratar de crecer. El asunto es que debe seguir moviéndose más rápido que el grande, buscando los nichos que este no acaba de satisfacer.

El peligro para el rápido viene cuando un grande (o varios) comienza a competir él. Es probable que no le arrebate todo el mercado, pero también es muy posible que esas mermas de su pastel hagan que el rápido ya no tenga suficiente alimento, debilitándose y dejando el camino allanado al grande.

Gestión de proyectos, Procesos

Los procesos por los que discurre un proyecto son siempre los mismos, teniendo más o menos nivel de formalización o documentación en cada uno de ellos, dependiendo de lo 'rigurosos' que seamos con la metodología. En mi opinión los pasos fundamentales hay que respetarlos, y extendernos más o menos en un proceso dependerá mucho del tipo, volumen o actores del proyecto.

Iniciación

Es fundamental clarificar, a alto nivel, los objetivos (alcance) y los recursos que serán necesarios, para asegurar la disponibilidad de los mismos.

Es igualmente importante vincular, desde este primer momento, a aquellos actores (clientes, interesados,..) que participarán, utilizarán o se verán afectados por el proyecto, facilitando así su implicación y colaboración futura. De esta forma será más fácil que finalmente se sientan satisfechos con el resultado final.

Ya sólo nos queda formalizar documentalmente lo anterior y la aprobación del inicio del proyecto por parte del Patrocinador en el Acta de formalización del proyecto.

Es muy recomendable, si es posible, realizar una sesión semi-formal semi-lúdica de kick-off o lanzamiento del proyecto, con todos aquellos que vayan participar (al menos los más relevantes), de modo que se recuerden los objetivos, recursos y plazos y se comience con Alegría!!!

Planificación

Puede parecer que esta etapa se realiza únicamente al iniciarse el proyecto, pero no es así, es una tarea continua, es más, cuanto más revisiones hagamos, más detallado y preciso será nuestro plan. 

Inicialmente se hará el esfuerzo más importante, se clarificará algo más el alcance, se inventariarán y valorarán los recursos a emplear, las necesidades de productos o servicios, el cronograma del proyecto y los niveles de calidad o aceptación requeridos. Se incluye en esta fase la realización del Plan de Gestión del proyecto, que reflejará las directivas de cómo se va gestionar el proyecto. Por ejemplo, se procedimentará como vamos a medir los avances, los costes o los pasos a seguir para realizar las compras o adquisiciones.

En esta fase es conveniente contar con aquellos miembros que, por su experiencia o conocimiento, nos puedan ayudar a realizar las estimaciones de tiempos y recursos, sobre todo si el Jefe de proyecto no es un experto en la materia. ¿Quién mejor que aquellos que van a participar los trabajos para realizar las valoraciones de los mismos? Preguntar es bueno!!

Ejecución

Es casi autoexplicativa. Se ejecutan los procesos y tareas para completar los trabajos, así como la coordinación de personas y recursos con el fin de facilitar los avances. En esta fase es muy importante que fluya la información entre los ejecutores para evitar bloqueos, duplicación de tareas o malos entendidos.
Tan importante como hacer las tareas es comunicarlo.

Seguimiento y control

Observaremos la ejecución y mediremos el rendimiento, con el fin de identificar problemas o dificultades para avanzar con normalidad. Es crítico anticiparse e ir allanando el terreno para que el proyecto discurra lo más fluido posible.

En esta fase también iremos detectando los cambios en el alcance, recursos o tiempos, identificándolos para tomas las acciones correspondientes, dentro de la fase de re-planificación, que pudieran incluir incluso la cancelación del proyecto si se tratara de una situación grave.

La detección de cambios o problemas debe ser una tarea compartida por el equipo, para ello es conveniente generar un clima de confianza y respeto entre todo el equipo y hacia el Jefe de proyecto. Además de detectar los problemas conjuntamente, es posible plantear conjuntamente las mejoras, a través de un sistema de lecciones aprendidas.

Resumiendo:

• Observar y medir, como herramientas de mejora (No se trata de formar una "Stasi" como en la RDA)
• La potencia sin control no sirve de nada (Anuncio de Pirelli)

Cierre

Un proyecto siempre finaliza, con o sin éxito, pero finaliza. Igual que en la iniciación, es necesario 'institucionalizar' el cierre formalmente. Si ha habido éxito es recomendable gratificar a los integrantes del proyecto por el esfuerzo realizado, al menos con una palmadita en la espalda y si puede ser algo más.

Antes del cierre, el Jefe de proyecto deberá asegurarse de dejar documentada y actualizada toda la información del proyecto. Dentro de esa información es muy relevante lo referido a Lecciones aprendidas. Esta información del proyecto deberá pasar al equipo de Operaciones, que deberá realizar la explotación del producto o servicio del proyecto.

Ax2012, Debugging managed code desde Visual Studio

En una entrada anterior hemos visto como poder acceder a la lógica de negocio y datos de Ax desde Visual Studio. Ahora se trata de revisar los parámetros que nos permitirán trazar nuestro código VS, incluyendo la parte que se ejecuta en Ax. Para ello debemos tener en cuenta:

• AOS, Configuración del servidor
• Activar 'Habilitar puntos de interrupción para depurar el código X++ que se ejecuta en este servidor' 
• Activar 'Habilitar puntos de interrupción globales'
• Cliente Ax, Configuración
• Activar 'Habilitar puntos de interrupción  de usuario para depuración del código en el Business Connnector'
• Activar 'Habilitar puntos de interrupción globales para ejecución de código en el Business Connector o cliente'
• Usuario Ax, opciones
• En la pestaña Desarrollo, Modo de depuración: Mediante el punto de interrupción
• Equipo cliente
• El usuario logeado que va a realizar el debug debe estar en el grupo local 'Microsoft Dynamics AX Debugging Users'

Únicamente nos queda establecer los puntos de interrupción en código alcanzable por las llamadas realizadas desde Visual Studio y tener en ejecución el programa Microsoft Dynamics Ax Debugger, de esta forma cuando lancemos nuestra aplicación VS podremos ver como la ejecución se para en los puntos de interrupción establecidos y trabajaremos normalmente con el Debugger de Ax y VS.

Finalmente recordar que todos estos parámetros deben estar idealmente desactivados en el entorno Producticvo, mejorando así el rendimiento al evitar que tenga que analizar si debe activar el debug

Nota: Los puntos de interrupción globales en principio no son necesarios, salvo que vayamos a trazar código de Enterprise Portal o ejecutado por BCProxy

Ax2012, Ejecutando lógica Ax desde VS mediante Ax.ManagedInterop

Introducción

La interoperabilidad es una de las características fundamentales que a día de hoy debemos exigir a la hora de seleccionar una solución. Expresa la capacidad de comunicarse y entenderse con otros sistemas, proporcionando interfaces para exponer información y, a un mayor nivel, proporcionar acceso a la lógica de proceso. Es igualmente importante que nuestro software sea capaz de "consumir" información y procesos de terceros.

En versiones previas de Ax, como 2.5 y 3.0, existía el llamado Business Connector, que era una DLL que daba acceso a la lógica y a la información mediante unos interfaces generalizados. Su configuración y funcionamiento era compleja y poco intuitiva. Pues bien, todo eso ha cambiado con Ax2012, ahora con las herramientas de desarrollo para Visual Studio el acceso a la lógica es más sencilla e intuitiva ya que nos crea 'proxies' de los objetos de Ax que necesitamos desde Visual Studio, trabajando por tanto de forma 'tipada' e incluso con Intellisense.

Ejemplo básico

El ejemplo consiste en acceder al nombre de un grupo de clientes (CustGroup). Para ello en Visual Studio,

• Crear un proyecto de tipo 'Biblioteca de clases' (Class Library)

• Botón derecho sobre el proyecto, Add to AOT. (Esto añadirá el proyecto al AOT del entorno que tengamos configurado en el equipo sobre el que estamos desarrollando). Una vez añadido verás que el icono del proyecto cambia, apareciendo 
• En la barra de menú de VS, Ver -> Application Explorer. Nos aparecerá una vista del AOT. 
• Seleccionar el objeto al cual queremos acceder y arrastrarlo al proyecto. En este ejemplo la tabla CustGroup. En este momento creará el proxy y añadirá la referencia al Ax.ManagedInterop
• Modificar la clase Class1.cs que se generó con el proyecto, indicando el siguiente código:

using System;

using Microsoft.Dynamics.AX.ManagedInterop;

namespace GCC_VSAOT

{

    public class AxBL : IDisposable

    {

        Session session;

        public AxBL()

        {

            session = new Session();

            session.Logon(null, null, null, null); //Conectará a la empresa y configuración por defecto del usuario

        }

        public string _cName(string _cu)

        {

            CustGroup cu = new CustGroup();

            cu = CustGroup.find(_cu);                 //Al tener ya creado el proxy nos aparece la clase y sus métodos

            return cu.Name;

        }

        public void Dispose()

        {

            session.Logoff();

        }

    }

}

• Crear un proyecto de tipo 'Aplicación de consola' (Console Application)
• Añadimos una referencia a nuestro proyecto anterior, en mi caso llamado GCC_VSAOT
• Modificar el Program.cs, dejando el siguiente código:

using System;

using GCC_VSAOT;

namespace GCC_VSAOT_ConsoleTest

{

    class Program

    {

        static void Main(string[] args)

        {

            AxBL bl = new AxBL();

            Console.Write(bl._cName("CU"));     //Pasar un código de Grupos de Cliente

            Console.ReadKey();

            bl.Dispose();

            using (AxBL bl2 = new AxBL())           //Con using al ser IDisposable hará el Dispose al final del bloque

            {

                Console.Write(bl2._cName("CE"));    //Pasar un código de Grupos de Cliente

                Console.ReadKey();

            }

        }

    }

}

Problemas

1. Al compilar el proyecto de consola. Solución: Establecer .Net Framework 4 como framework destino (igual que el proyecto de librería) y no .Net Framework 4 Client Profile
2. Al ejecutar. Solución: Añadir al proyecto de consola un App.Config, con lo siguiente:

<?xml version="1.0"?>

<configuration>

  <startup useLegacyV2RuntimeActivationPolicy="true">

    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

  </startup>

</configuration>

Más detalles sobre estos y otros problemas con la conectividad Ax-VS visita el blog de mi compañero Juanma, http://www.overflowexception.es/

Ax2012, Fechas UTC y DateTimeUtil

Esta versión de Ax ha incorporado un nuevo mecanismo de validez temporal (date effectiveness) de los registros, permitiendo en las tablas añadir este mecanismo para mantener la información pasada, presente y futura, sin conflicto entre ellas.

Este nuevo mecanismo almacena las fechas en formato UTC, y hemos de tener muy presente este aspecto si no queremos llevarnos sorpresas, ya que la función validTimeState trabaja con las fechas UTC.

Ejemplo: Si estamos en España e introducimos como valor inicial de un registro 01/04/2013 10:10:10, el sistema almacenará en SQL 01/04/2013 08:10:10 (dos horas menos), aunque siempre nos mostrará la primera en formularios e informes, ya que aplica la diferencia horaria.

Los problemas pueden venir por dos vías:

1. Si leemos la tabla directamente en SQL y no tratamos el valor de fecha, nos parecerá que el registro entró en vigor a las 08:10:10.
2. Si accedemos vía x++ pero construimos la fecha y hora por código para la función validTimeState y no la pasamos a UTC, podemos estar leyendo una información incorrecta.

Para clarificar el problema y conocer las funciones que nos ayudarán a trabajar con fecha UTC tengo preparado el siguiente JOB:

static void GCC_ValidezTemporal(Args _args)

{

    utcDateTime             utcDatetimeUsr,utcDatetimeUTC;    

    date                    _date;

    TimeOfDay               _time;    

    int                     timezoneOffset;

    

    ;

    info(strFmt("Fecha UTC mínima: %1 (no se representa pero es 1900-01-01T00:00:00) y máxima: %2",DateTimeUtil::minValue(),DateTimeUtil::maxValue()));

    

    utcDatetimeUsr = str2datetime("01/04/2013 10:10:10",123);

    utcDatetimeUTC =  DateTimeUtil::newDateTime(DateTimeUtil::date(utcDatetimeUsr),DateTimeUtil::time(utcDatetimeUsr),DateTimeUtil::getCompanyTimeZone());

    timezoneOffset = DateTimeUtil::getTimeZoneOffset(utcDatetimeUsr,DateTimeUtil::getCompanyTimeZone());    

    info(strFmt("Fecha para el usuario: %1, Fecha UTC: %2, Offset: %3", utcDatetimeUsr,utcDatetimeUTC,timezoneOffset));

    

    utcDatetimeUsr = str2datetime("31/12/2013 10:10:10",123);

    utcDatetimeUTC =  DateTimeUtil::newDateTime(DateTimeUtil::date(utcDatetimeUsr),DateTimeUtil::time(utcDatetimeUsr),DateTimeUtil::getCompanyTimeZone());

    timezoneOffset = DateTimeUtil::getTimeZoneOffset(utcDatetimeUsr,DateTimeUtil::getCompanyTimeZone());    

    info(strFmt("Fecha para el usuario: %1, Fecha UTC: %2, Offset: %3", utcDatetimeUsr,utcDatetimeUTC,timezoneOffset));

    

    _date = mkDate(01,04,2013);

    utcDatetimeUsr = DateTimeUtil::newDateTime(_date,_time);

    info(strFmt("Fecha creada desde DMY (la que el usuario ve): %1",utcDatetimeUsr));

    utcDatetimeUsr =  DateTimeUtil::newDateTime(DateTimeUtil::date(utcDatetimeUsr),DateTimeUtil::time(utcDatetimeUsr),DateTimeUtil::getCompanyTimeZone());

    info(strFmt("Su correspondiente UTC: %1",utcDatetimeUsr));    

    utcDatetimeUsr = DateTimeUtil::applyTimeZoneOffset(utcDatetimeUsr,DateTimeUtil::getCompanyTimeZone());

    info(strFmt("Volvemos a la fecha según la ve el usuario: %1",utcDatetimeUsr));        

}

Sabios consejos de Warren Buffet

Gestión de proyectos, Marco conceptual

Trataré de resumir los conceptos fundamentales en la disciplina de Gestión de proyectos (Project Management) (fuente principal, PMBOK 4)

¿Qué es un Proyecto?

Un proyecto es un esfuerzo temporal (con inicio y fin) para crear un resultado único. Normalmente se elaboran de forma gradual, por fases o etapas, para una mejor organización de los trabajos.
Su nacimiento suele estar ligado a la respuesta a:

• Demanda del mercado u organización
• Avance tecnológico
• Cambios legales 

Operaciones vs Proyectos

Las operaciones son continuas y repetitivas, mientras los proyectos son temporales y únicos.

Ejemplo: La implantación de un nuevo procedimiento de copias de seguridad en una compañía sería un proyecto. La llevanza o motorización del funcionamiento de ese procedimiento de copias de seguridad formaría parte de las operaciones del departamento responsable de las mismas.

Ciclo de vida

Normalmente los proyectos se dividen en fases para facilitar su gestión. Habitualmente en cada fase se hace más hincapié en ciertos procesos o tareas. Es muy importante siempre formalizar las fases de inicio y fin. Por otro lado, resaltar la diferencia entre el ciclo de vida del proyecto, y el ciclo de vida del producto final, este último ciclo podría desembocar en nuevos proyectos de mejora o actualización, pero estos no forman parte del proyecto inicial. Gráficamente:

Dirección de proyectos

Consiste en la aplicación de conocimientos, habilidades y herramientas para satisfacer los requisitos del proyecto. El director del proyecto será el responsable de guiar el proceso hacia la consecución de los objetivos, su trabajo incluye:

• Establecer objetivos claros y posibles de realizar
• Identificar los requisitos
• Equilibrar las demandas concurrentes de requerimientos (alcance), tiempo, costes y calidad
• Adaptar las especificaciones, planes y enfoques a las expectativas de los interesados

Para realizar su trabajo correctamente el director de proyectos debe conocer:

• Fundamentos de la dirección de proyectos. (metodología)
• Conocimientos del ámbito de aplicación de proyecto. (comprensión funcional del proyecto)
• Conocimiento del entorno del proyecto (ámbito social, cultural, físico, político relacionado)
• Conocimiento generales de dirección (Gestión financiera, marketing, compras,...)
• Habilidades interpersonales (Muy importante! Influencia en la organización, liderazgo, motivación, gestión de conflictos y problemas, negociación)

Los interesados

Se trata de todas aquellas personas u organizaciones que pueden verse vinculados o afectados por el proyecto. Es importante recalcar que es posible que implique no sólo al personal interno de la organización. Podríamos definir las siguientes figuras:

• Director del proyecto. La persona responsable de dirigir el proyecto.
• Patrocinador. La persona o el grupo que proporciona los recursos financieros, monetarios o en especie, para el proyecto.
• Cliente/usuario. La persona u organización que utilizará el producto/servicio del proyecto.
• Organización ejecutante. La empresa cuyos empleados participan directamente en el trabajo del proyecto.
• Miembros del equipo del proyecto. El grupo que realiza el trabajo del proyecto.
• Equipo de dirección del proyecto. Los miembros del equipo del proyecto que participan directamente en las actividades de dirección del proyecto.
• Influyentes. Personas o grupos que no están directamente, pero que, debido a su posición o relación con la organización del cliente u organización ejecutante, pueden ejercer una influencia positiva o negativa sobre el curso del proyecto.