Procesos de aprobación: ¿con tareas o con campos empresariales?

Una de las mayores novedades de Project Server/Online 2013 es la posiblidad de realizar flujos de trabajo mediante Sharepoint Designer. De esta manera, ya no es obligatorio el desarrollo mediante Visual Studio de flujos para la gestión de la cartera o de la demanda.

Durante estos procesos de negocio suele ser necesario el realizar validaciones/aprobaciones de la información introducida por parte de algunos actores. Este proceso de aprobación puede realizarse de dos maneras: con tareas de flujos de trabajo o con algún campo personalizado de empresa mediante el cual introducir la decisión de aprobador.

Aprobación mediante tareas de flujo de trabajo

Esta sería la aproximación clásica para cualquier flujo de trabajo, tanto de Project Server cómo de Sharepoint. Cuando sea necesario que alguien realice alguna aprobación sobre la información introducida por alguno de los actores, se le asigna una tarea desde la cuál realizar dicha aprobación.El resultado de la misma permite tomar una decisión sobre hacia dónde debe dirigirse el flujo de trabajo.

Los flujos de Sharepoint Designer nos permiten crear y asignar tareas mediante dos actividades diferentes:

  • Asignar una tarea: mediante esta actividad asignamos una única tarea a un usuario o a un grupo de Sharepoint. En este último caso, no se crea una tarea para cada uno de los miembros del grupo, si no que se crea una única tarea para todo el grupo. El resultado de la tarea (aprobado o rechazado) será el del primer usuario del grupo que interactúe con ella.
  • Iniciar un proceso de tarea: esta actividad también permite asignar tareas a un único usuario o a un grupo de Sharepoint. Sin embargo, ofrece una mayor personalización del proceso de aprobación y personalización de las tareas. Por ejemplo, en caso de asignarse a un grupo de Sharepoint, se crea una tarea para cada uno de sus miembros. Además, permite indicar si estas tareas individuales se crean en paralelo (todas a la vez) o secuencialmente (no se creará la siguiente tarea para un miembro hasta que haya aprobado o rechazado el miembro anterior). Incluso permite personalizar cómo se toma la decisión final a partir de las decisiones individuales de cada uno de los miembros del grupo: la primera respuesta es la válida, por mayoría de aprobados o rechazados, cuando llegue el primer aprobado…

En ambos casos, se envía un correo electrónico a los aprobadores para informarles de que deben realizar alguna acción.

Además, las tareas se pueden visualizar fácilmente tanto desde la colección de sitios de Project Web App como desde los sitios de proyecto, con lo que se pueden mostrar, por ejemplo, desde la página de inicio del sitio principal. De esta forma, si el usuario pierde el correo electrónico informándole de la tarea, puede ver lo que tiene pendiente siempre que entre en el sitio de Project Web App.

Sin embargo, las tareas tienen un problema con la seguridad. Aunque, por defecto, los usuarios sólo ven las tareas asignadas a sí mismos, es posible que un usuario que tenga permisos de edición sobre la lista de tareas puede ver el contenido de una tarea que no tenga asignada y aprobarla o rechazarla. La única forma de garantizar la seguridad es rompiendo la herencia a nivel de elemento y dejando con permisos sobre la tarea únicamente al grupo o usuario que la tenga asignada. Esto se puede hacer con un flujo de Sharepoint Designer en la lista de tareas de Project Server cuyas acciones se ejecuten dentro de un paso de aplicación. El flujo se lanzaría cada vez que se cree o se edite un elemento.

Aprobación mediante campos empresariales en las PDP

El único pero que se le pueden poner a las tareas es que obligan a realizar una acción fuera de las páginas de proyecto. Para realizar una validación de la información introducida es necesario ir al proyecto para revisarla y, además, ir a la tarea para aprobar o rechazar el proceso. En ocasiones, esto no es del agrado de los usuarios de negocio.

Es posible sustituir la validación de las tareas por un campo empresarial en el que almacenar la decisión del aprobador. Este campo de empresa se puede mostrar en cualquier página de detalle de proyecto, con lo que no se rompe el flujo natural de revisión de la información. Se suele incluir también algún campo en el que introducir los comentarios que se consideren oportunos.

El campo empresarial para la decisión puede ser de tipo “Flag” (Sí/No) o, si se requieren valores adicionales u otros valores, se puede usar una tabla de búsqueda empresarial (Enterprise Lookup Table).

Para informar de que se requiere revisar la información es necesario enviar un correo a los usuarios involucrados. Sin embargo, si este correo se pierde, no hay ninguna tarea a mostrar en la página principal del sitio de Project Web App, con lo que los usuarios deberían revisar el centro de proyectos para ver cuáles están pendientes de validación.

Al igual que las tareas, el mayor problema que presenta esta solución es el de la seguridad. Los flujos de trabajo de Project Server / Online no ofrecen ningún tipo de seguridad a nivel de usuario o grupo respecto a la visibilidad de las páginas. Es decir, cualquier usuario que tenga permisos para ver un proyecto y publicar la información del mismo podría realizar la validación que debería de hacer otro usuario. El mayor problema es, sobre todo, con el Project Manager (PM), el propietario del proyecto. Normalmente, las validaciones realizadas son sobre la información introducida por este último. Y, como propietario del proyecto, está claro que puede acceder a todas las páginas del mismo en cualquier momento del flujo. Algunas soluciones a este problema pueden ser las siguientes:

  • Cambiar al propietario del proyecto por algún usuario del grupo de los validadores antes de realizar la validación y volver a poner al PM después de la misma. Sin embargo, realizar este proceso de forma manual es engorroso y pueden producirse olvidos. Sería necesario un flujo desarrollado con Visual Studio para hacer mantenible esta solución.
  • Añadir en las audiencias del webpart en el que se muestran los campos para realizar la aprobación al grupo de validadores según la etapa del flujo que corresponda. De esta forma, aunque el PM tenga acceso a esta página, no verá el webpart y no podrá suplantar los resultados de la decisión.Sin embargo, esto implica revisar en profundidad los permisos a nivel de Sharepoint de los grupos de usuarios que tienen acceso a los proyectos en todas sus etapas para que no puedan realizar acciones como editar las páginas (con lo que podrían quitar la audiencia del webpart) o modificar los permisos de los grupos (con lo que, si les quitan los permisos para editar las páginas, podrian volver a ponérselos). Aunque es una buena solución, puede darse el caso en el que no sea posible quitar todos los permisos a algún grupo debido a las necesidades del mismo.
 Conclusiones

Tanto las tareas como los campos empresariales son formas adecuadas de realizar la validación en los flujos de trabajo de Project Server. Simplemente hay que ver cómo se adaptan a las necesidades de nuestro proceso de negocio. Incluso, pueden combinarse en diferentes etapas del flujo de trabajo.

Personalmente, me gustan más las aprobaciones mediante tareas, aunque es cierto que la aprobación mediante campos empresariales se integra de una forma más natural en el proceso de negocio para los flujos de Project Server / Online.

Anuncios