Gestión económica de los proyectos – Caso práctico: calendario de facturación

En nuestro anterior post acerca de la Gestión económica de los proyectos con Project Server dimos indicaciones sobre cómo plantear esta gestión económica y los pros y contras de las diferentes implementaciones. Hemos pensado que sería interesante mostrar un caso práctico mediante alguna funcionalidad relacionada con la gestión financiera de un proyecto. A tal efecto, hemos optado por implementar un calendario de facturación. El objetivo es mostrar el razonamiento que se debe utilizar para buscar la mejor opción posible entre las posibilidades que Project Server/Online nos ofrece.

Empezaremos por describir la necesidad de negocio: se requiere generar un calendario de facturación para cada proyecto y, así, poder definir de forma personalizada diferentes hitos de cobro. También sería interesante poder validar que se ha generado o enviado la factura, por ejemplo.

El requisito parece simple pero en su enunciado ya podemos detectar algunos elementos que nos proporcionan pistas sobre cómo debe ser la implementación del mismo. Por ejemplo, el hecho de definir de forma personalizada para cada proyecto los diferentes hitos de cobro. Como ya hemos comentado anteriormente, todos los campos personalizados de empresa que se generen están disponibles para todos los proyectos. Así pues, si se generasen campos para almacenar los diferentes hitos de pago a nivel de Project Server, tendríamos los siguientes inconvenientes:

  • Habría que generar tantos campos como fuesen necesarios para cada uno de los proyectos. Con lo que, cada vez que se generase un nuevo proyecto, habría que crear sus campos correspondientes para los hitos de facturación. El mantenimiento sería costosísimo con el tiempo.
  • Al generar campos empresariales por cada proyecto, se perdería la homogeneidad del sistema y no se podrían desarrollar flujos de Project que controlasen la facturación pues utilizarían campos diferentes. Esto obligaría a crear un flujo diferente por cada proyecto. Inmantenible.

No obstante, habría una opción de implementar algo sencillo en Project. En este caso, la solución consistiría en crear un campo personalizado de empresa de tipo “flag” para indicar si la tarea es un hito de facturación. De esta forma, el Jefe de Proyecto podría visualizar en la planificación los hitos de facturación directamente. Incluso se podrían añadir dichas tareas al “Timeline”  del proyecto y del Centro de Proyectos (Project Center) y mejorar así su seguimiento:

Hito_Facturacion_Project

Sin embargo, no sería posible realizar un flujo de validación relacionado con los hitos.

Si se requiere algo más flexible y que permita usar flujos para validar la consecución del hito, por ejemplo, sólo nos queda una opción: implementar la funcionalidad a nivel de Sharepoint. Y, en este caso, lo mejor es utilizar el calendario que existe en el sitio del proyecto.

Para flexibilizar aún más la implementación, es conveniente generar un tipo de contenido para los eventos de facturación a nivel de la colección de sitios de PWA. De esta forma, se consiguen los siguientes beneficios:

  • Se pueden crear campos a medida para los hitos de facturación según la necesidad de negocio: responsable del hito, si se ha generado factura, si se ha cobrado…

Hito_Facturacion_Campos

  • Se puede añadir el tipo de contenido al calendario de los sitios de proyecto y diferenciar los eventos de facturación de otros eventos del proyecto.

     Hito_Facturacion_NewCT

  • Se facilita la generación de informes al poder obtener todos los eventos con este tipo de contenido de todos los sitios de proyectos a la vez.
  • Se puede generar un flujo de trabajo asociado al tipo de contenido para realizar validaciones, generar tareas, enviar correos al Dpto. de facturación…
  • Este tipo de contenido se puede añadir a la plantilla del sitio de proyecto y generarse así automáticamente para todos los proyectos.

Conclusión

Como comentábamos al principio, la finalidad de esta entrada es completar el anterior post con un caso práctico de ejemplo que permitiera comprender mejor el proceso de decisión de la arquitectura de una solución de gestión económica de los proyectos. Se han obviado las soluciones basadas en desarrollo (desarrollando se puede hacer prácticamente cualquier cosa…) para centrarse en personalización de las herramientas out-of-the-box que nos ofrece Project Server, puesto que el producto es lo suficientemente flexible como para resolver la mayoría de necesidades de negocio que se puedan plantear. Y la gestión financiera de los proyectos no iba a ser menos.

La idea principal con la que debemos quedarnos es que si se requiere una implementación personalizada y diferente para cada proyecto, debemos plantearnos soluciones a nivel de Sharepoint. En cambio, si se busca homogeneizar los proyectos y definir un proceso común para todos, probablemente debamos centrarnos en la capa de Project para resolver el requisito de negocio.

Anuncios