Versión del 5 de junio: mejoras de gobernanza, Stage Gates y flujo de trabajo

Esta versión se centra especialmente en ayudar a las PMO a fortalecer la gobernanza sin dificultar la ejecución práctica de los procesos de entrega. Las actualizaciones abarcan Stage Gates, flujos de trabajo, documentos, planeación, informes y gestión financiera, y brindan a las organizaciones un mejor control sobre cómo los proyectos avanzan a través de aprobaciones, revisiones y puntos de control de gobernanza, sin dejar de permitir que los equipos se adapten cuando cambian las circunstancias.

La mayor inversión se concentra en los Stage Gates, que ahora admiten una gama más amplia de escenarios de gobernanza: las aprobaciones pueden reiniciarse cuando cambian las circunstancias, las puertas pueden ser informativas o gestionarse mediante flujos de trabajo externos, y la nueva función Stage Gate Packages permite a los equipos ejecutar ciclos de aprobación repetibles dentro de una misma fase. Las puertas también pueden delimitarse a tipos de proyecto específicos y consolidarse en los proyectos principales, dando a los gerentes de programa visibilidad sobre la gobernanza de los proyectos secundarios sin necesidad de abrir cada proyecto individualmente.

Los flujos de trabajo y los procesos de aprobación también han recibido actualizaciones importantes: los flujos de trabajo de proyecto ahora pueden crear subproyectos automáticamente, las aprobaciones pueden asignarse por rol de proyecto, y un nuevo Project Workflow Configuration Inspector ofrece a los administradores una vista con capacidad de búsqueda e instantánea de toda la configuración del flujo de trabajo.

La gestión de documentos se ha mejorado sustancialmente, con nuevas opciones de filtrado y agrupación en el panel de Documentos y una nueva vista de consolidación que permite a los proyectos principales mostrar documentos de sus subproyectos directos, útil para los gerentes de programa que revisan evidencia de gobernanza en toda una jerarquía.

Además, hemos introducido los Informes de estado en borrador, que dan a los gerentes de proyecto más control sobre cuándo se publican los informes; los Informes de estado estrictos y la Gestión estricta de riesgos y problemas para mejorar la calidad y la consistencia de los datos; controles de cronograma más estrictos mediante elementos de cronograma protegidos y el nuevo nivel de promoción L5 – Suprimido; los Proyectos confidenciales para restringir el acceso a trabajo sensible; y un nuevo Modelo de capitalización simplificado para las organizaciones que desean reglas de capitalización más amplias e independientes de la fase.

Para las PMO, el tema general es una gobernanza más clara, mejor trazabilidad y un control más práctico a lo largo del ciclo de vida del proyecto. Para los equipos de proyecto, estos cambios reducen el trabajo manual, mejoran la consistencia y facilitan operar dentro del enfoque de gobernanza que su organización ha definido.

---

Cada Stage Gate puede configurarse con una Restart Policy que controla si — y quién — puede reiniciar la decisión de aprobación de una puerta. Esto es especialmente útil cuando las circunstancias del proyecto cambian después de haberse tomado una decisión en una puerta — por ejemplo, si surgen nuevos riesgos o se han rehecho entregables —, dando a las PMO la flexibilidad de reevaluar una puerta sin necesidad de crear un nuevo proceso.

La configuración de Restart Policy está disponible en el área de administración de puertas y se aplica exclusivamente a las puertas que utilizan el modo Approval; las puertas configuradas como Declared, Informational o External Workflow siempre tendrán por defecto Not Restartable. Hay tres opciones:

• Not Restartable (predeterminado) — la decisión de aprobación de la puerta es definitiva y no puede reabrirse.

• Project Managers — los usuarios con permisos de gestión de proyecto pueden reiniciar la puerta.

• Project Administrators Only — solo los administradores del proyecto pueden reiniciar la puerta.

Una puerta solo puede reiniciarse si pertenece a la fase actual del proyecto. Las puertas de fases pasadas (por las que ya se avanzó) no pueden reiniciarse, incluso si la Restart Policy y los permisos del usuario lo permitirían de otro modo. Esto garantiza que reiniciar una puerta solo se utilice para revisar una decisión relevante para el punto en que se encuentra actualmente el proyecto, evitando cambios no deseados en fases completadas o en fases que el proyecto aún no ha alcanzado.

Reiniciar una puerta la reabre, vuelve a hacerla bloqueante y restablece el flujo de aprobación según el tipo de puerta. En las puertas de aprobación basadas en decisión, la solicitud existente se restablece para que los mismos aprobadores puedan tomar una nueva decisión. En las puertas de aprobación basadas en flujo de trabajo, la tarjeta de acción se traslada de nuevo a la primera columna para que pueda avanzar de nuevo por el flujo de trabajo, conservando el historial de decisiones anterior como referencia.

No hay límite en cuántas veces puede reiniciarse una puerta — cada vez que la puerta se cierra posteriormente (aprobada o rechazada), puede volver a reiniciarse siempre que el usuario cuente con los permisos requeridos y la puerta permanezca en la fase actual.

La Restart Policy se configura por puerta, lo que permite distintos niveles de control entre las puertas de una misma fase o metodología. Si el modo de una puerta se cambia posteriormente y deja de ser Approval, la Restart Policy se restablece automáticamente a Not Restartable.

Puede leer más sobre cómo reiniciar Stage Gates aquí.

Cuando se reinicia una Stage Gate basada en flujo de trabajo, los documentos ya sincronizados con el proyecto permanecen en su lugar. Si la acción de aprobación se actualiza con documentos revisados y se envía nuevamente, Fluid compara la nueva presentación con los documentos existentes del proyecto, archiva las versiones anteriores y añade las versiones más recientes a la carpeta activa del proyecto.

Esto brinda a las PMO y a los gerentes de proyecto un registro de auditoría claro de lo que se aprobó en cada etapa, a la vez que facilita encontrar la versión aprobada vigente. Si la protección de documentos está habilitada, tanto los documentos sincronizados del proyecto como los documentos de origen en la acción de flujo de trabajo quedan protegidos como parte del proceso de aprobación.

Para más detalles, consulte el artículo de la base de conocimientos sobre documentos en Stage Gates basadas en flujo de trabajo.

Ahora puede configurar Stage Gates de tipo Informational para escenarios en los que desea mostrar información relevante sin bloquear el avance del proyecto.

Las puertas Informational son no bloqueantes y siempre se tratan como cerradas en Fluid. A diferencia de las puertas Declared, que se cierran manualmente, o de las puertas Approval, que requieren autorización, las puertas Informational no requieren ninguna acción de puerta en el sistema para que el proyecto pueda avanzar.

Pueden utilizarse para mostrar contexto útil en un punto específico del ciclo de vida del proyecto, como orientación, información de apoyo, o un enlace a un informe externo, panel, documento o flujo de trabajo.

Las puertas Informational también admiten una Hyperlink Expression, que permite generar enlaces dinámicos específicos del proyecto utilizando valores de campo como [Id] o [ExternalReference], o valores de propiedades personalizadas. Esto significa que puede dirigir a su equipo directamente a un informe de BI filtrado, una página de SharePoint o cualquier otro sistema externo relevante para el proyecto, sin que nadie necesite buscar la URL por su cuenta.

Puede leer más sobre las Stage Gates Informational aquí.

Ahora puede utilizar External Workflow como un nuevo tipo de Stage Gate para proyectos en los que el estado de la puerta es gestionado por una aplicación o flujo de trabajo externo, en lugar de por los usuarios en Fluid.

Esta puerta está diseñada para escenarios de gobernanza impulsados por integraciones. En lugar de ser cerrada manualmente por los gerentes de proyecto, la puerta es actualizada por un sistema externo — como Power Automate, Power Apps, ServiceNow, Jira o Azure DevOps —, que escribe el estado de la puerta de vuelta en Fluid a través de la Fluid V3 API.

Cuando se añade a una fase, la puerta es visible en el espacio de trabajo para que los usuarios puedan ver si está abierta, en curso o cerrada, pero no pueden cerrarla ellos mismos. La aplicación externa sigue siendo el origen de la decisión de la puerta, mientras que Fluid refleja el estado actual en el proyecto.

También puede configurar un enlace dinámico en la puerta para dirigir a los usuarios directamente al flujo de trabajo, formulario o herramienta de aprobación externa que gestiona la acción.

Al igual que con otras puertas, si Enabled Blocking Phase Stage Gates está activado, la fase no puede avanzar hasta que la puerta se cierre — en este caso, por el sistema externo conectado.

Las puertas External Workflow pueden combinarse opcionalmente con una aprobación de Fluid. Cuando se configura un Approval Type en la puerta (como Named, Executive, Business Owner, Owner o Portfolio Approver), la solicitud de cierre del sistema externo no cierra la puerta de inmediato. En su lugar, Fluid crea una tarea de aprobación formal para el aprobador configurado. La puerta permanece bloqueada hasta que el aprobador la autoriza — lo que le brinda un modelo de gobernanza en dos pasos en el que el sistema externo activa la revisión y un aprobador de Fluid toma la decisión final.

Este nuevo tipo de puerta ofrece a los equipos una forma más limpia de respaldar procesos de gobernanza que ocurren fuera de Fluid, sin dejar de mantener la visibilidad de la puerta y el control del proyecto dentro de Fluid. Es especialmente útil cuando no se debe permitir la anulación manual.

Lea la guía de usuario completa sobre External Workflow Gates y External Workflow Gates Paired with Approvals.

Algunas fases de proyecto necesitan el mismo conjunto de aprobaciones más de una vez — por ejemplo, un ciclo de aprobación por cada versión de software, ronda de evaluación de proveedores o ciclo de auditoría. Stage Gate Packages facilita esto al permitir que los administradores definan un paquete reutilizable de puertas que los gerentes de proyecto pueden iniciar tantas veces como sea necesario dentro de una fase.

Los administradores ahora pueden crear un paquete, añadir las puertas requeridas en el orden correcto y asignarlo a una fase de metodología como Package Gate.

Una vez disponible en un proyecto, los gerentes de proyecto pueden iniciar una nueva instancia de paquete, darle un nombre significativo como “Versión 1 — junio de 2026”, y avanzar por las puertas secundarias generadas igual que con las Stage Gates estándar.

Cada instancia de paquete tiene su propio conjunto de puertas, estado, aprobaciones, flujos de trabajo y seguimiento de progreso.

Pueden ejecutarse varias instancias en paralelo, y la Package Gate general se cierra automáticamente una vez que todas las puertas secundarias de todas las instancias están completas. Si se reabre alguna puerta secundaria, el estado del paquete principal también se actualiza automáticamente.

Obtenga más información en el artículo Stage Gate Packages.

Las Stage Gates ahora pueden mostrarse solo en los proyectos donde son relevantes. Al configurar una puerta en su metodología, use Project Applicability para decidir si la puerta debe aparecer en todos los proyectos, solo en los proyectos principales, solo en los proyectos secundarios, en proyectos sin proyectos secundarios, o en proyectos que no son secundarios de otro.

Esto ayuda a mantener más ordenadas las metodologías para los equipos que trabajan con estructuras de proyecto principal-secundario. Por ejemplo, las puertas a nivel de programa pueden limitarse a los proyectos principales, mientras que las puertas a nivel de entrega pueden mostrarse solo en los proyectos secundarios.

Para obtener más información sobre cada opción y cuándo utilizarla, consulte el artículo Stage Gate Applicability.

Los gerentes de programa y los responsables de portafolio ahora pueden hacer seguimiento a los puntos de control de gobernanza clave de los proyectos secundarios directamente desde el proyecto principal.

Hay disponible una nueva configuración Promote to Parent en las Stage Gates. Cuando está habilitada, la puerta se muestra automáticamente en la vista Stage Gates del proyecto principal como una fila informativa de solo lectura. Esto significa que los proyectos principales pueden mostrar el estado actual de puertas importantes de proyectos secundarios, como Go-Live Approval u otros puntos de decisión clave, sin que los usuarios necesiten abrir cada proyecto secundario individualmente.

Las puertas promovidas se siguen gestionando en el proyecto secundario con normalidad. Los gerentes de proyecto pueden accionarlas, los aprobadores pueden aprobarlas, y la puerta puede cerrarse desde el proyecto secundario. En el proyecto principal, la puerta promovida es solo informativa y no puede accionarse, aprobarse, reabrirse ni cerrarse.

En el proyecto principal, los usuarios pueden ver el nombre del proyecto secundario, el estado actual de la puerta promovida y un enlace de regreso al proyecto secundario para una navegación rápida. Si hay instancias de paquete promovidas en curso en proyectos secundarios, cada instancia iniciada se muestra por separado con su progreso, como 3 de 5 puertas cerradas.

Para habilitar esto, los Project Administrators pueden ir a Admin → Methodologies, Phases and Tasks Setup → Stage Gates, editar la puerta correspondiente, establecer Promote to Parent en Yes, y guardar. Una vez que se aplique o se vuelva a aplicar la metodología, las puertas coincidentes de los proyectos secundarios directos se consolidarán automáticamente en el proyecto principal.

Puede leer más sobre la promoción de Stage Gates al proyecto principal aquí.

• Expressions – datos financieros del proyecto: los valores financieros del proyecto ahora están disponibles en el contexto de expresiones para las Stage Gates y las Governance Assessments. Esto significa que las expresiones pueden hacer referencia a indicadores financieros clave, como valores reales, previsiones, estimate at completion, financiamiento, presupuesto, variación presupuestaria, ingresos y valor ganado, al determinar si una puerta aplica o si se cumple una regla de gobernanza.

  Esto permite a las organizaciones crear reglas de gobernanza con mayor conciencia financiera; por ejemplo, mostrar una puerta solo cuando se prevé que un proyecto supere su financiamiento del año en curso, cuando una variación presupuestaria supera un umbral definido, o cuando un proyecto ha utilizado una proporción alta de su financiamiento aprobado.

• Navegación de configuración de metodología: ahora es más fácil encontrar y gestionar registros de configuración en la página Methodology, Phases, Tasks & Stage Gate Management. Las seis pestañas de configuración ahora incluyen un cuadro de búsqueda instantánea que filtra por nombre y descripción a medida que se escribe, con una opción para restablecer la búsqueda rápidamente.

  Las pestañas Stage Gates y Phase Gates también incluyen filtros adicionales, que permiten a los administradores acotar los resultados por metodología, fase, aprobador o modo de puerta. Estos filtros pueden combinarse con la búsqueda, lo que agiliza la localización de la puerta o el elemento de configuración correcto sin desplazarse por listas de configuración extensas.

• Stage Gates – edición masiva: las Stage Gates ahora pueden actualizarse mediante edición masiva, lo que facilita aplicar cambios en varios registros de forma más eficiente. Puede leer más sobre esta nueva funcionalidad aquí.

• Project Audit History: la página Project Audit History ahora incluye una sección dedicada a las aprobaciones del proyecto. Esta sección enumera las aprobaciones asociadas con el proyecto junto con detalles clave como la fecha de aprobación, el aprobador, el estado del flujo de trabajo y cualquier comentario ingresado en la decisión.

• Stage Gates – actualizaciones en vivo: se añadieron actualizaciones en vivo de puertas dentro del espacio de trabajo para que los gerentes de proyecto puedan ver de inmediato los cambios en el estado de las puertas y las fases.

• Stage Gates – SLA de aprobación: establecer el valor Duration for Approval de una puerta en 0 ahora indica que la puerta no tiene SLA ni fecha de vencimiento.

• Refresh Stage Gates: los Project Administrators ahora pueden aplicar los últimos cambios en la definición de Stage Gates a un proyecto específico directamente desde el espacio de trabajo del proyecto. Para actualizar las Stage Gates de un proyecto, abra el menú Tools y seleccione Apply Stage Gates. Esto facilita mantener los proyectos individuales alineados con los procesos de gobernanza actualizados sin necesidad de cambios más amplios en el proyecto.

---

Cuando los equipos necesitan entregar el trabajo en etapas definidas — como versiones, paquetes de trabajo o entregas por fases —, los subproyectos suelen necesitar seguir una estructura consistente. Esta actualización le da más control sobre cómo se crean esos subproyectos, ayudando a garantizar que cada uno se configure en el lugar correcto, con la información correcta, en el momento correcto de su flujo de trabajo.

Con Project Workflow en un tablero Project Pipeline, ahora puede configurar una columna para crear automáticamente un subproyecto cuando una tarjeta se mueve a ella. Esto es especialmente útil para los equipos de entrega Agile que gestionan varias versiones desde un proyecto principal, donde cada versión necesita su propio proyecto secundario para planeación, seguimiento e informes. En lugar de crear los proyectos de versión manualmente, los equipos pueden usar el flujo de trabajo para crearlos de forma más consistente y gobernada.

Cuando una tarjeta llega a una columna Create Project configurada, Fluid crea un nuevo subproyecto debajo del proyecto principal vinculado. El nuevo subproyecto usa el título de la tarjeta como su nombre y traslada las propiedades de tarjeta coincidentes, los documentos adjuntos y los detalles de proyecto relevantes. Si las columnas posteriores están configuradas para sincronizar, la misma tarjeta puede seguir actualizando el subproyecto existente a medida que avanza por el flujo de trabajo.

Para obtener orientación de configuración paso a paso y más detalles, consulte el artículo de ayuda completo.

Ahora puede hacer visibles los flujos de trabajo de proyecto para usuarios que no son administradores de proyecto cuando se les incluye explícitamente en la lista Limited Work Request de un flujo de trabajo. Esto significa que los usuarios autorizados a activar flujos de trabajo específicos a nivel de proyecto — como actualizar datos del proyecto o crear subproyectos — ya no necesitan permisos de administrador de proyecto solo para verlos y ejecutarlos. El cambio elimina una restricción innecesaria y facilita que las personas adecuadas ejecuten los flujos de trabajo que se les han asignado.

La función Project Workflow ahora mantiene sincronizadas las propiedades de primera clase incluso después de haberse creado un proyecto. Anteriormente, las propiedades coincidentes solo se copiaban de la tarjeta de flujo de trabajo al proyecto durante la creación inicial.

Con esta actualización, si un flujo de trabajo de proyecto está configurado para sincronizar propiedades en una columna, cualquier cambio en esas propiedades en la tarjeta también actualizará las propiedades correspondientes en el proyecto a medida que la tarjeta avanza por etapas posteriores del flujo de trabajo. Esto garantiza que los datos de su proyecto se mantengan actualizados a medida que evolucionan, sin depender únicamente del paso de configuración inicial.

Para configurar una columna de tablero de modo que sincronice propiedades de vuelta al proyecto, active Project Workflow para la columna y luego establezca Project handling en Sync Properties. También puede elegir si mover una tarjeta a esa columna debe actualizar el estado del proyecto vinculado o dejar el estado del proyecto sin cambios.

Las tarjetas de flujo de trabajo vinculadas a un proyecto ahora pueden actualizarse para incorporar los metadatos más recientes del proyecto. Esto ayuda a mantener actualizados los campos relacionados con el proyecto en la tarjeta cuando cambian los valores en el proyecto vinculado.

La actualización se aplica a cualquier propiedad elegible configurada como Read Only for Everyone, incluidas las propiedades de proyecto de primera clase, como la metodología o el tipo de proyecto, así como las propiedades personalizadas asignadas desde el proyecto.

Actualización manual: desde la navegación izquierda de la tarjeta, seleccione Refresh Project Metadata y luego confirme la actualización. Fluid sincronizará las propiedades de solo lectura elegibles desde el proyecto vinculado y mostrará una notificación con el resultado, incluyendo qué propiedades se actualizaron cuando se detecten cambios.

Actualización automática: las tarjetas en la primera columna (de solicitud) del tablero también actualizan los metadatos del proyecto automáticamente al abrirse — no se requiere ninguna acción. Esto se ejecuta silenciosamente en segundo plano antes de que se cargue la tarjeta, siempre que la tarjeta esté vinculada a un proyecto, no esté cerrada, y el usuario tenga permiso de Editor o superior.

Para más detalles, incluidas las reglas de disponibilidad y lo que ocurre después de la actualización, consulte el artículo Refresh Project Metadata on Workflow Cards.

Para que las solicitudes de flujo de trabajo sean más fáciles de reconocer y gestionar, cualquier solicitud activada desde un proyecto — ya sea desde una Stage Gate o un flujo de trabajo de proyecto — ahora mostrará automáticamente la referencia de proyecto correspondiente en la tarjeta. La misma referencia también se añadirá a cualquier decisión asociada con ese flujo de trabajo.

Anteriormente, las solicitudes de flujo de trabajo y las decisiones relacionadas solo mostraban el título del proyecto. Si bien esto ayuda, no siempre es el identificador que utilizan las PMO, los gerentes de portafolio y los aprobadores al revisar proyectos en un portafolio. Incluso cuando un proyecto se crea directamente en Fluid mediante Project Intake, la referencia del proyecto suele convertirse en el identificador clave utilizado en la gobernanza del día a día. En algunos casos, los equipos también mantienen una referencia externa para vincular Fluid con otros sistemas de negocio o procesos posteriores. Mostrar la referencia relevante directamente en las solicitudes y decisiones de flujo de trabajo facilita reconocer el proyecto correcto de un vistazo, reduce la ambigüedad durante la revisión y respalda aprobaciones más rápidas y seguras.

De forma predeterminada, la referencia mostrada sigue este orden: Alternate Reference, luego External Reference, y luego Project ID.

Las decisiones de solicitudes de flujo de trabajo ahora muestran la fecha en que se aprobaron o rechazaron directamente en la tarjeta de decisión. Antes, solo se mostraba el estado, lo que dificultaba entender exactamente cuándo se había tomado una decisión.

Al mostrar la fecha de la decisión, los equipos obtienen un registro de auditoría más claro, mejor contexto histórico y una forma más sencilla de dar seguimiento al progreso de las solicitudes y a la actividad de gobernanza de un vistazo.

El Project Workflow Configuration Inspector es una herramienta de administración de solo lectura que le brinda una visión completa y con capacidad de búsqueda de cómo están configurados los flujos de trabajo de proyecto y las Stage Gates de su organización.

Está disponible únicamente para los Project Administrators y los Application Administrators, y se puede acceder a ella desde el área de administración en Admin → Project Workflow Config.

El inspector genera automáticamente una instantánea de su configuración actual y le permite explorarla en varias categorías (Project Properties, Person Properties, Workflow Boards, Stage Gates, Portfolios, Shared Lists y First Class Properties), de modo que pueda comprobar rápidamente cómo están configurados los campos, tableros y etapas sin necesidad de navegar por cada pantalla de configuración individualmente.

En cualquier momento, puede tomar una instantánea de la configuración en vivo para registrar de forma permanente cómo está configurado todo en ese momento. Estas instantáneas se guardan con una marca de tiempo y el nombre de la persona que las creó, generando un historial de versiones al que puede volver más adelante. Desde el panel de historial puede explorar instantáneas anteriores, abrir cualquier versión pasada para revisar cómo era la configuración en ese momento, descargar instantáneas como archivos JSON para referencia o difusión fuera de línea, y eliminar instantáneas que ya no se necesiten.

Puede buscar por palabra clave para encontrar campos o configuraciones específicos, ver el historial de instantáneas de configuración anteriores y descargarlas para revisión o registro fuera de línea.

Es especialmente útil cuando necesita auditar la configuración de su flujo de trabajo, solucionar por qué un campo o tablero se comporta de cierta manera, o compartir los detalles de su configuración con colegas o equipos de soporte.

Las decisiones de aprobación de flujo de trabajo ahora pueden asignarse en función de los roles del proyecto. Anteriormente, los aprobadores podían establecerse como el solicitante, el propietario de la columna, el asignado de la tarjeta, o mediante una expresión dinámica.

Con esta actualización, también puede seleccionar aprobadores basados en roles de proyecto, como Portfolio Approver, Business Sponsor, Technology Owner, Executive o Project Primary PM, para que las aprobaciones sigan los roles de gobernanza correctos para cada proyecto con mayor precisión.

• Project Pipeline Boards – tarjetas en borrador: los flujos de trabajo de proyecto siguen exigiendo una única tarjeta en borrador por proyecto; sin embargo, los usuarios pueden enviar varias tarjetas en borrador a tableros de Project Pipeline genéricos sin restricción.

• Registro de Project Workflow: una nueva configuración controla si el registro detallado de flujo de trabajo está activo. Cuando está habilitado, se escriben mensajes de diagnóstico detallados en los registros y se publican en los canales de chat de las tarjetas de flujo de trabajo durante la sincronización de documentos — útil al configurar o solucionar problemas de flujos de trabajo complejos en entornos de sandbox. La configuración se encuentra en Administration Console, en Setup Project Features.

---

Hemos mejorado la sección de Documentos para facilitar la búsqueda y organización de documentos de proyecto, especialmente cuando los proyectos contienen un gran número de archivos, resultados de flujo de trabajo o presentaciones de gobernanza.

El panel de Documentos ahora incluye un panel lateral Filters & Options donde los usuarios pueden buscar documentos, cambiar cómo se agrupan los documentos y aplicar los filtros disponibles.

Los usuarios ahora pueden abrir el panel Filters & Options desde la sección de Documentos para buscar documentos, controlar qué se incluye en la vista, filtrar la lista y agrupar los documentos de la forma que mejor respalde su revisión.

Las opciones disponibles pueden incluir:

• Find — buscar por nombre de documento o nombre de archivo.

• Show Archive — incluir documentos archivados al revisar archivos anteriores o históricos.

• Include Sub Projects — incluir documentos de subproyectos directos, cuando la consolidación de documentos está disponible.

• Show Folder Hierarchy — mostrar los documentos dentro de su estructura de carpetas.

Los usuarios también pueden filtrar documentos por valores disponibles, como:

• Status — por ejemplo, Approved o Draft.

• Type — como Design, Document, Project Charter o Statement of Work.

• Workflow — filtrar documentos vinculados a un flujo de trabajo específico, cuando corresponda.

• Folder — centrarse en documentos almacenados en una carpeta específica.

• Phase — filtrar por fase de proyecto o de gobernanza, cuando corresponda.

• Stage Gate — filtrar documentos vinculados a una Stage Gate específica, cuando corresponda.

• Package — filtrar documentos de Package Gate, cuando corresponda.

Los usuarios también pueden agrupar documentos utilizando las opciones de agrupación disponibles para ese proyecto, lo que facilita revisar los documentos según la estructura o el contexto que más importe.

Tenga en cuenta que los filtros, los valores de filtro y las opciones de agrupación que se muestran dependen de los documentos disponibles en el proyecto. Por ejemplo, los filtros de Stage Gate, fase, flujo de trabajo y paquete solo son visibles cuando el proyecto tiene documentos vinculados a esas estructuras de gobernanza o de flujo de trabajo.

Para los documentos de Stage Gate, Fluid también admite una jerarquía de carpetas basada en gobernanza. Los documentos de puerta estándar se organizan por Phase > Gate, mientras que los documentos de Package Gate se organizan por Phase > Gate > Package Instance. Esto facilita la revisión de documentos presentados para un punto de control de gobernanza, una puerta o una ejecución de paquete específicos.

Puede leer más sobre estos cambios en nuestros artículos sobre Managing Project Documents y Document Filters & Options

Al completar un Project Workflow o una Stage Gate, los usuarios ahora pueden seleccionar un documento de proyecto existente para una Custom Property de tipo Documento, en lugar de subir un archivo duplicado.

Esto es útil cuando ya existe evidencia de respaldo en el proyecto, como un caso de negocio, un paquete de aprobación, un documento de financiamiento o un archivo de gobernanza. Los usuarios pueden reutilizar el documento existente como evidencia para un Work Request, lo que ayuda a mantener la documentación del proyecto consistente y a reducir las cargas duplicadas.

Cuando corresponda, los usuarios también pueden seleccionar documentos de proyectos relacionados dentro de la misma jerarquía de proyectos, incluido el proyecto principal directo, sus subproyectos y los proyectos hermanos que comparten el mismo proyecto principal directo. Esto respalda la gobernanza a nivel de programa, en la que los documentos clave se gestionan a nivel principal y se reutilizan en los flujos de trabajo o Stage Gates de los proyectos secundarios. También ayuda a los equipos a reutilizar evidencia entre subproyectos relacionados sin crear copias de documentos adicionales.

Por ejemplo, un proyecto puede tener varios subproyectos, cada uno representando una versión diferente. Algunos artefactos de la versión, como un paquete de aprobación, evidencia de pruebas, una lista de verificación de despliegue o un documento de lecciones aprendidas, pueden completarse para una versión y luego reutilizarse como evidencia de respaldo para una versión futura. En lugar de volver a subir esos archivos, los usuarios pueden vincular el documento existente desde el subproyecto de versión relacionado.

Cuando se selecciona un documento existente, Fluid almacena una referencia al archivo de documento seleccionado. El archivo subyacente se reutiliza, pero los metadatos del documento permanecen específicos al contexto en el que el documento está vinculado, como el flujo de trabajo, la Stage Gate, el historial de aprobación o el proyecto relacionados. La referencia apunta a la versión específica del archivo seleccionada en ese momento, lo que respalda una gobernanza y auditabilidad más claras.

Puede leer más sobre este cambio en Linking Existing Project Documents to Work Request Document Custom Properties.

Revisar los documentos de proyecto en un programa o una estructura principal-secundaria ahora es mucho más sencillo.

Los proyectos principales ahora pueden mostrar documentos de subproyectos vinculados directamente en el mismo panel de Documentos, ofreciendo a los equipos un solo lugar para revisar materiales de respaldo, evidencia de gobernanza y entregables de proyecto en toda la jerarquía de proyectos.

El panel de Documentos puede mostrar:

• Documentos almacenados directamente en el proyecto actual.

• Documentos de subproyectos vinculados.

• El proyecto de origen de cada documento consolidado.

Los documentos consolidados no se copian al proyecto principal. Siguen siendo propiedad de su proyecto de origen, los permisos del proyecto de origen siguen aplicando, y las actualizaciones de metadatos se guardan de vuelta en el proyecto de origen. El proyecto principal ofrece una vista consolidada, no un almacén de documentos independiente.

De forma predeterminada, el panel de Documentos incluye los documentos de subproyectos para que los usuarios puedan ver de inmediato el conjunto más amplio de documentos en toda la jerarquía. Los usuarios pueden usar Filter & Options para desmarcar Include Sub Projects cuando solo deseen ver los documentos almacenados directamente en el proyecto actual.

Los documentos de subproyectos se identifican claramente con una etiqueta de proyecto de origen, lo que facilita ver de dónde proviene cada documento.

Puede leer más sobre la consolidación de documentos aquí.

Los usuarios también pueden abrir los metadatos de un documento para ver su Approval History.

Cuando un documento ha sido aprobado a través de un Project Workflow, una Stage Gate u otro proceso de aprobación, el historial de aprobación se muestra directamente en los metadatos del documento. Esto brinda a los usuarios un registro claro de la decisión de aprobación, incluidos el flujo de trabajo o la solicitud relacionados, el estado de la aprobación, cuándo se aprobó y a quién se asignó la aprobación.

Esto facilita entender de dónde proviene un documento, confirmar si ya ha sido revisado, y rastrear el proceso de gobernanza detrás de los documentos de proyecto aprobados.

• Estado del documento: los Application Administrators ahora pueden establecer el estado predeterminado que se aplica a los documentos nuevos, navegando a la página Metadata desde Administration Console.

  Los Project Administrators también pueden ahora elegir si se usan y se muestran los estados de documento, navegando a la página Setup Project Features desde el Administration Console. Cuando el estado de documento está desactivado, los campos y filtros de estado se ocultan en la carga, edición, vistas y exportaciones de documentos

• Document Links: también se ha añadido una nueva configuración de aplicación para controlar si los usuarios pueden añadir enlaces de documento. Cuando está deshabilitada, los usuarios solo pueden subir archivos físicos, y se oculta la opción de añadir un documento mediante una URL web como referencia de documento.

• Ver documentos PDF en Fluid: cuando sube un documento PDF a Fluid, este queda disponible para visualizarse directamente en su navegador web, sin necesidad de descargarlo primero. Simplemente haga clic en el documento y se abrirá en una nueva pestaña del navegador, donde el visor de PDF integrado de su navegador le permite leer, desplazarse y hacer zoom en el archivo. Si un documento acaba de subirse y el sistema aún lo está preparando, es posible que vea un breve mensaje pidiéndole que lo intente de nuevo en un momento — esto es normal y el archivo estará listo en breve.

• Propiedades personalizadas de documento: al configurar una Custom Property de tipo Document, los administradores ahora pueden especificar el tipo de documento que debe aplicarse a los archivos subidos. Esto es especialmente útil para los Project Workflows, donde los documentos aprobados suelen quedar protegidos y sus metadatos no pueden modificarse después, lo que ayuda a garantizar que los documentos queden organizados correctamente desde el principio.
  

  

• Exportación de documentos a Excel: las exportaciones de documentos ahora incluyen una opción para exportar documentos activos y archivados o solo documentos activos. La exportación también se ha mejorado para incluir detalles adicionales de gobernanza, como el flujo de trabajo, la fase, la puerta, la instancia de paquete y la subpuerta con la que está asociado el documento.

---

Hemos añadido dos nuevas comprobaciones de gobernanza para ayudar a las PMO a identificar proyectos donde los cronogramas o los impactos podrían no estar recibiendo una revisión regular. Al señalar los proyectos donde los datos clave no se han actualizado dentro de un plazo definido, estas comprobaciones facilitan impulsar una acción oportuna por parte de los gerentes de proyecto.

Schedule Recently Updated
Esta comprobación evalúa si algún elemento del cronograma se ha actualizado dentro de un plazo que usted defina. Si no se han realizado actualizaciones durante ese período, el proyecto se marca para atención.

Mantener los cronogramas actualizados es una responsabilidad esencial de los gerentes de proyecto. Esta comprobación brinda a las PMO una forma sencilla de detectar proyectos cuyos datos de cronograma podrían ya no reflejar el plan más reciente y donde podría requerirse seguimiento.

Impacts Recently Updated
Esta comprobación evalúa si algún impacto abierto se ha actualizado dentro del plazo elegido. Si los impactos abiertos no se han revisado recientemente, el proyecto se marca para atención.

Los gerentes de proyecto deben revisar regularmente los impactos para garantizar que los riesgos y las consecuencias sigan siendo precisos. Esta comprobación ayuda a las PMO a identificar dónde los datos de impacto podrían estar desactualizados, para que puedan impulsar una revisión oportuna antes de que se pasen por alto los problemas.

---

Ahora puede proteger elementos clave del cronograma para que no puedan renombrarse, recategorizarse ni eliminarse por usuarios que no sean administradores.

Esto es especialmente valioso al crear plantillas de proyecto, donde las fases estándar, los hitos, los entregables y los puntos de control de gobernanza deben incluirse en cada proyecto creado a partir de esa plantilla. Al establecer estos elementos como protegidos de antemano, las PMO y los Project Administrators pueden asegurarse de que la estructura de cronograma importante permanezca en su lugar mientras los gerentes de proyecto ajustan el resto del plan.

Una vez que se activa Enable Protected Schedule Items en Feature Settings, los Project Administrators pueden marcar elementos del cronograma como protegidos. Esto puede hacerse directamente en el cronograma o mediante edición masiva e importaciones de plantillas usando la columna Protected.

Cuando un elemento está protegido, los usuarios que no son administradores no pueden:

• cambiar el título

• cambiar el tipo o el subtipo

• eliminar el elemento

• eliminar un elemento principal que contiene elementos secundarios protegidos

Aún pueden actualizar otros detalles de planeación, como fechas, estado, asignaciones y progreso.

Esto facilita estandarizar la gobernanza del cronograma entre proyectos sin volver inflexible todo el plan.

Puede leer más sobre los elementos de cronograma protegidos aquí.

Ahora puede marcar elementos del cronograma como L5 – Suprimido para eliminarlos del plan activo sin borrarlos. Esto es útil para trabajo fuera de alcance, fases diferidas o tareas de plantilla que deben conservarse como referencia pero ya no incluirse en los informes.

Cuando un elemento del cronograma se establece en L5 – Suprimido, permanece visible en el Gantt del proyecto pero se trata como inactivo. Los elementos suprimidos se excluyen de los cronogramas de portafolio, hojas de ruta, watchlists, componentes de cronograma promovidos, informes de estado, cálculos del % de avance del proyecto y comprobaciones de gobernanza basadas en cronograma. Tampoco activan indicadores de retraso o vencimiento.

Si suprime un elemento principal, todos los elementos secundarios se suprimen automáticamente. Revertir el elemento de vuelta a L1–L4 lo restaura al plan activo.

Los usuarios con permiso Manage o superior pueden actualizar los niveles de promoción de forma individual o masiva.

Para obtener todos los detalles sobre el comportamiento, los permisos y los casos de uso recomendados, consulte el artículo de la base de conocimientos sobre elementos de cronograma inactivos.

Ahora puede actualizar el nivel de promoción de varias tareas a la vez en Edit Gantt View. Para usar esta función, primero seleccione las tareas que desea actualizar — la acción Change Promotion queda disponible una vez que se seleccionan tareas. Puede usar Shift para seleccionar un rango continuo de tareas, o Ctrl/Cmd para seleccionar tareas individuales.

Esto facilita ajustar rápidamente los niveles de promoción en un grupo de tareas, según el informe en el que esté trabajando, sin tener que actualizar cada tarea una por una. Como resultado, los usuarios pueden hacer cambios más rápido, trabajar de forma más eficiente en conjuntos de tareas más grandes, y mantener la configuración de promoción alineada de forma más consistente en todo su plan.

La configuración Enable Project Managers Baseline se ha actualizado para ofrecer más flexibilidad sobre quién puede crear líneas base.

Cuando la configuración está activada, los Project Managers pueden crear líneas base de los proyectos.

Anteriormente, cuando la configuración estaba desactivada, solo los Project Administrators podían hacerlo. Ahora, cuando la configuración está desactivada, los Portfolio Administrators también pueden crear líneas base. Esto amplía el acceso para las organizaciones que gestionan la creación de líneas base a nivel de portafolio.

• Cronograma – Edit Gantt View: se añadieron nuevas columnas para mostrar Baseline Dates y Baseline Variance to End Date, lo que facilita el seguimiento de la desviación del cronograma directamente en la cuadrícula del Gantt.

• Schedule Action Tasks: ahora las acciones de cronograma pueden crearse sin requerir un asignado.

• Schedule Sub Types: se amplió el conjunto de caracteres admitidos para los nombres de subtipo de cronograma, para incluir ,, ., / y #.

---

Hemos introducido la Gestión estricta de riesgos y problemas para ayudar a las organizaciones a mejorar la calidad, la consistencia y la utilidad de los datos de riesgos y problemas en todo el portafolio. En muchos casos, los riesgos y problemas se registran con información parcial únicamente, lo que puede generar ambigüedad en la propiedad, debilitar los informes y dificultar el seguimiento eficaz de las acciones de mitigación. Esta función aborda este problema exigiendo a los usuarios completar campos clave antes de poder guardar un riesgo o problema.

La función se controla mediante el feature flag Disable Strict Risk and Issue Reporting, que puede configurarse en Administration Console > Setup Project Features. Cuando el modo estricto está habilitado, los usuarios deben completar todos los campos obligatorios antes de guardar un riesgo o problema. Estos campos incluyen Description, Impact, Probability, Owner, Due Date y Mitigation.

La validación estricta se aplica únicamente a Risks y Issues. Otros tipos de impacto, como Assumption, Dependencies, Changes o Lessons Learned, no se ven afectados.

Para obtener todos los detalles sobre el funcionamiento del flag, incluida su lógica invertida y los tipos de impacto afectados, consulte Strict Risk and Issue Management.

En programas y portafolios grandes, no todos los impactos (como riesgos, problemas, dependencias, decisiones y lecciones) permanecen relevantes para siempre. Algunos pueden quedar fuera de alcance, resolverse fuera del flujo de trabajo formal, o simplemente registrarse como marcadores de posición. Anteriormente, estos saturaban los espacios de trabajo, los paneles y las vistas de gobernanza, afectando las métricas y desviando la atención de los elementos que realmente importan en el momento.

El nivel de promoción L5 – Suprimido resuelve esto al permitir que las PMO y los gerentes de proyecto “retiren” impactos de forma controlada. Los impactos suprimidos permanecen en el sistema para el registro de auditoría y referencia futura, pero ya no influyen en los informes, el cumplimiento ni las vistas del día a día del proyecto.

Cómo funciona

• Establecer como L5 – Suprimido: cualquier impacto (riesgo, problema, dependencia, decisión o lección) puede establecerse en L5 mediante el campo Promotion Level.

• Oculto en paneles e informes de portafolio: una vez suprimidos, estos impactos se excluyen de los paneles, la mayoría de las vistas de espacio de trabajo, las watchlists y los informes de consolidación. No aparecerán en las comprobaciones de gobernanza ni contribuirán a las métricas de cumplimiento.

• Reversible: la supresión no es permanente — las PMO y los gerentes de proyecto pueden restaurar un impacto actualizando su nivel de promoción de vuelta a L1–L4 en cualquier momento, devolviéndolo al flujo de trabajo y visibilidad activos.

Hemos introducido los Informes de estado estrictos para ayudar a mejorar la calidad, la consistencia y el control de los informes de estado de proyecto.

Cuando esta función está habilitada, los gerentes de proyecto solo pueden actualizar informes de estado con fecha de hoy o en el futuro, lo que ayuda a evitar cambios retroactivos en periodos de informes ya presentados. También hace obligatorios campos clave del informe de estado, incluidos Strapline, Achievements y Next Steps, de modo que los informes contengan la información mínima necesaria para una revisión y supervisión eficaces.

Los Project Administrators aún pueden editar informes con fecha pasada cuando sea necesario. Las mismas reglas también se aplican a la edición masiva, de modo que la edición masiva no puede usarse para eludir los controles de informes.

Esta función está desactivada de forma predeterminada y puede habilitarse desde Administration → Setup Project Features, en el grupo Project Health, por los Project Administrators.

Haga clic aquí para leer más sobre los informes de estado estrictos.

Hemos introducido Allow Draft Status Reports para dar a los gerentes de proyecto más control sobre cuándo se comparten los informes de estado.

Cuando esta función está habilitada, los usuarios ahora pueden elegir entre Save As Draft o Save And Publish al crear un informe de estado. Los informes en borrador permanecen como trabajo en curso y no se muestran en paneles, vistas de portafolio ni otros resultados de informes publicados hasta que se publiquen explícitamente.

Si existe un informe en borrador, la sección Status Report del espacio de trabajo del proyecto muestra un aviso amarillo. Los usuarios pueden seleccionar Edit Draft Report desde este aviso para reabrir el borrador, seguir trabajando en él, o eliminarlo si ya no se necesita.

Una vez publicado, el informe pasa a ser visible como parte de los informes formales. Si su organización también utiliza Informes de estado estrictos, el acceso de edición después de la publicación seguirá esas reglas.

La edición masiva también se ha actualizado. Cuando la función está habilitada, hay disponible una nueva columna PublishedStatus, que permite a los gerentes de proyecto ver y actualizar si un informe está establecido como Draft o Published.

Esta función está desactivada de forma predeterminada y los Project Administrators pueden habilitarla desde Administration → Setup Project Features, en el grupo Project Health.

Para leer más sobre los informes de estado en borrador, haga clic aquí.

Los Project Administrators ahora pueden configurar el campo Executive Summary en los informes de estado de dos nuevas maneras:

• Renombrar el campo Executive Summary: mediante Project Labels & Field Names, los administradores pueden cambiar la etiqueta del campo para que coincida con la terminología de su organización.

• Mostrar u ocultar el campo Executive Summary: mediante el feature flag Enable Status Report Executive Summary, los administradores pueden controlar si el campo está disponible en los informes de estado, los paneles y las exportaciones. Cuando está deshabilitado, el campo se oculta en la interfaz, se excluye de las exportaciones a Excel y se ignora en el cargador de Excel si la columna está presente.

Esto brinda a los equipos más flexibilidad para alinear los informes de estado con su lenguaje interno y sus necesidades de reporte. Para obtener todos los detalles de configuración, consulte Configure the Strapline and Executive Summary on Status Reports.

Los administradores ahora pueden definir un conjunto independiente de estados RAG para las tareas de cronograma y los elementos de impacto, como riesgos, problemas, supuestos, dependencias, decisiones y lecciones aprendidas.

Anteriormente, estos elementos utilizaban los mismos estados RAG que los informes de estado de proyecto y de programa. Esto significaba que las opciones utilizadas para los informes formales de proyecto también debían funcionar para el seguimiento diario de tareas e impactos, aun cuando estas áreas suelen necesitar etiquetas, valores predeterminados o niveles de detalle diferentes.

Con esta actualización, las tareas de cronograma y los impactos ahora pueden usar sus propios estados RAG a nivel de elemento. Esto brinda a las organizaciones más control sobre cómo se hace seguimiento a los elementos de entrega, mientras se mantiene el enfoque de los informes de estado del proyecto en la salud general del proyecto.

Los Application Administrators pueden configurar estos valores desde Administration > Metadata Management > Item Status RAGs. Desde esta nueva página de metadatos, los administradores pueden añadir y gestionar las opciones RAG utilizadas para las tareas de cronograma y los impactos, incluyendo la etiqueta, el color, el peso, el estado predeterminado, el estado activo y la descripción.

Tenga en cuenta que, cuando las organizaciones no deseen hacer seguimiento ni mostrar el historial de estado RAG para las tareas de cronograma y los impactos, la aplicación también puede configurarse para ocultar la pestaña Status Updates y el panel de historial RAG en los diálogos de cronograma e impacto.

• Impact Risk Matrix: el Impact Risk Matrix se ha actualizado para que el gráfico muestre de forma predeterminada RAG por subtipo. Los usuarios aún pueden cambiar a RAG por nivel de riesgo mediante el interruptor cuando deseen revisar la distribución de riesgos por nivel.

• Informes de estado – RAG general: se corrigió el comportamiento para que el Overall RAG pueda editarse de forma independiente cuando Allow Edit Overall RAG está habilitado, en lugar de ser sobrescrito por los valores RAG de los componentes.

---

Ahora puede marcar proyectos como Confidential para limitar la visibilidad y el acceso únicamente a los usuarios explícitamente nombrados en el proyecto.

Cuando un proyecto se marca como confidencial, se elimina el acceso otorgado mediante roles globales amplios y el proyecto se oculta en lugares como la búsqueda, los paneles de portafolio y las jerarquías de programa. Esto significa que los usuarios con roles como Project Viewer o Portfolio Administrator no pueden ver ni acceder a proyectos confidenciales a menos que se les haya añadido explícitamente al proyecto.

La configuración Confidential solo puede habilitarse o actualizarse por usuarios con el rol Project Administrator, ya sea en la configuración del proyecto o mediante Bulk Edit. Los Project Administrators siguen teniendo acceso a los proyectos confidenciales para poder gestionar la configuración cuando sea necesario.

Los proyectos confidenciales le brindan un control más estricto sobre las iniciativas sensibles, ayudando a garantizar que solo las personas adecuadas puedan verlos y gestionarlos.

Para obtener todos los detalles sobre el funcionamiento de los proyectos confidenciales, consulte el artículo de la base de conocimientos Confidential Projects.

---

Fluid ahora admite dos modelos de capitalización: el modelo Comprehensive existente y el nuevo modelo Simplified. El modelo seleccionado se configura a nivel de aplicación, de modo que cada entorno utiliza un modelo de forma consistente en lugar de elegir un modelo por proyecto.

La aplicación también está configurada para utilizar la Implementation Date del proyecto o la Project End Date como fecha límite de capitalización. Esta fecha límite ayuda a definir la ventana capitalizable del proyecto, junto con la Capitalization Lock Date y las reglas del periodo financiero aplicables.

El modelo Comprehensive aplica reglas más detalladas basadas en las fases del proyecto, las tareas y la configuración de amortización, mientras que el modelo Simplified utiliza criterios de elegibilidad más amplios basados en el proyecto, el rol, el tipo de gasto y la fecha.

• Previsiones de recursos

  En ambos modelos, las previsiones de recursos solo son capitalizables cuando la fecha de la previsión cae dentro de la ventana de capitalización de previsión válida: después de la Capitalization Lock Date, antes de la fecha límite de proyecto configurada — ya sea la Implementation Date o la Project End Date —, y dentro de un periodo financiero abierto.
  
  La diferencia está en cómo se evalúa la elegibilidad del rol.

  • En el modelo Comprehensive, el recurso debe estar previsto contra un rol que sea capitalizable para la fase de proyecto específica en la que cae la previsión.

  • En el modelo Simplified, las fases se ignoran; la previsión se capitaliza si el proyecto es elegible y el rol es capitalizable.
    

• Valores reales de recursos

  En ambos modelos, los valores reales de recursos se evalúan según la fecha de la hoja de horas y se procesan dentro de la ventana de procesamiento de valores reales elegible, que abarca el periodo financiero bloqueado más un mes adicional después de ese periodo. La fecha de la hoja de horas debe ser posterior a la Capitalization Lock Date y anterior a la fecha límite de proyecto configurada — ya sea la Implementation Date o la Project End Date.

  La diferencia está en qué determina si la entrada de hoja de horas es capitalizable.

  • En el modelo Comprehensive, la entrada de hoja de horas debe registrarse contra una tarea capitalizable dentro de una fase de proyecto capitalizable.

  • En el modelo Simplified, las tareas y las fases no se consideran; los valores reales se capitalizan si el proyecto es elegible y la tabla de tarifas y el tipo de gasto del recurso son capitalizables.
    

• Previsiones sin recursos

  La misma lógica de capitalización se aplica en ambos modelos. Las previsiones sin recursos se capitalizan si el proyecto es elegible, el tipo de gasto tiene un porcentaje de capitalización superior al 0 % y la fecha financiera de la previsión cae dentro de la ventana de capitalización de previsión válida: después de la Capitalization Lock Date, antes de la fecha límite de proyecto configurada — ya sea la Implementation Date o la Project End Date —, y dentro de un periodo financiero abierto.

  Las previsiones posteriores a esa fecha límite se tratan como costos operativos.
  

• Valores reales sin recursos

  En ambos modelos, los valores reales sin recursos deben cargarse mediante el proceso de edición masiva compatible, incluir un porcentaje de capitalización, ser posteriores a la Capitalization Lock Date, y procesarse dentro de la ventana de procesamiento de valores reales elegible, que abarca el periodo financiero bloqueado más un mes adicional después de ese periodo.

  La diferencia está en cómo se aplica la fecha límite de proyecto configurada.

  • En el modelo Comprehensive, la fecha financiera del valor real debe ser anterior a la fecha límite configurada — ya sea la Implementation Date o la Project End Date.

  • En el modelo Simplified, los valores reales sin recursos aún pueden capitalizarse después de esa fecha límite de proyecto, siempre que se cumplan los demás criterios.

 

Puede leer más sobre capitalización aquí.

---

Hemos actualizado la forma en que se muestran y gestionan los subproyectos desde los proyectos y programas principales, facilitando la revisión de los proyectos que se encuentran bajo un proyecto principal y la comprensión de su estado actual de un vistazo.

Anteriormente, la información de subproyectos estaba dividida en áreas separadas: una sección enumeraba los subproyectos vinculados y permitía a los usuarios crear, vincular o desvincular proyectos, mientras que las secciones Promoted Status y Path to Green mostraban información de estado de proyecto promovida. Esto dificultaba que los gerentes de programa obtuvieran una vista única y consolidada del estado de los proyectos que conformaban un programa.

Estas vistas ahora se han combinado en una sola sección Sub-Projects. Los usuarios pueden ver los subproyectos vinculados junto con su información de estado más reciente en el mismo lugar, incluidos los detalles del informe de estado y la información de path-to-green cuando esté disponible.

Debido a que la sección ahora utiliza el componente Projects with Status, los usuarios también pueden usar Group By y Change View para revisar la información de diferentes formas, como detalles de proyecto, detalles completos de proyecto, gobernanza o vistas centradas en el estado.

En el caso de los programas, la sección Sub Projects también se ha trasladado más arriba en la página, de modo que los proyectos que conforman el programa sean más fáciles de encontrar y revisar. Tenga en cuenta que, en los programas, la sección se llama Projects.

Crear, vincular y desvincular subproyectos ahora se gestiona desde Tools → Manage Sub Projects. Esto abre un diálogo dedicado donde los usuarios autorizados pueden vincular proyectos existentes, crear nuevos subproyectos o desvincular proyectos del proyecto principal.

El acceso a estas acciones se controla de forma más estricta: los usuarios deben ser Project Administrators o contar con los permisos de edición requeridos sobre el proyecto y el rol Project Submission. Esto ayuda a las organizaciones a garantizar que solo los usuarios autorizados puedan crear o modificar las relaciones de jerarquía de proyectos.

• Exportación a PDF: las secciones de propiedades personalizadas ahora se muestran expandidas de forma predeterminada al usar la exportación a PDF, garantizando que todas las propiedades agrupadas sean visibles sin aparecer contraídas en el resultado.

• Página de inicio: el diseño de la página de inicio se ha actualizado para que las acciones clave del usuario sean más visibles. Timesheets y Requests ahora aparecen en la parte superior izquierda de la página, poniendo a la vista de inmediato las tareas más orientadas a la acción en cuanto los usuarios llegan a la página de inicio.

• General Settings - Home Page Setup: la sección Home Page Setup de la página General Settings le permite personalizar lo que ven los usuarios cuando llegan por primera vez a la página de inicio de Fluid. Hay tres configuraciones:

  • Home Page Header Content - esta es un área de contenido fija que aparece en la parte superior de la página de inicio, encima del carrusel. Puede usarla para mostrar un mensaje de bienvenida, la imagen de marca de la empresa, enlaces importantes o cualquier información estática que desee que vea todo usuario al iniciar sesión.

  • Show Home Page Carousel - este interruptor controla si se muestra en la página de inicio un banner de anuncios rotativo (carrusel). Configúrelo en Yes para mostrar el carrusel a todos los usuarios, o en No para ocultarlo.

  • Home Page Carousel Content - aquí es donde se añade el contenido que aparece dentro del carrusel. Puede crear varias diapositivas — cada diapositiva es un panel independiente que rota automáticamente en secuencia. Utilícelo para destacar anuncios, plazos próximos, actualizaciones clave o cualquier mensaje que desee transmitir a su equipo.

• Búsqueda global más inteligente: la búsqueda global se ha rediseñado para que encontrar el elemento correcto sea más rápido e intuitivo. Los resultados ahora se muestran en una lista más limpia y con capacidad de búsqueda, con el texto coincidente resaltado, lo que facilita ver por qué aparece cada resultado.

  También puede filtrar los resultados por tipo de principal, ordenarlos por nombre, recencia o fecha de creación, y alternar entre orden ascendente o descendente. Esto ayuda a los usuarios a acotar rápidamente conjuntos de resultados grandes y saltar al proyecto, tablero o reunión correctos con menos exploración y menos clics.

  

• Rendimiento de tableros: hemos mejorado el rendimiento de los tableros para tableros de alto volumen con un gran número de tarjetas y propiedades personalizadas. Los tableros con un número muy grande de tarjetas ahora cargan y responden de forma más eficiente, facilitando la gestión de flujos de trabajo grandes sin ralentizaciones.

• Propiedades personalizadas numéricas: las propiedades personalizadas de tipo número ahora se muestran alineadas a la izquierda, de forma consistente con otros tipos de propiedad. Esto facilita examinar los valores en ventanas grandes y proporciona un diseño más limpio y consistente.

• Exportación de hojas de horas a Excel: los usuarios ahora pueden seleccionar uno o más estados de hoja de horas antes de descargar la exportación a Excel de hojas de horas, de modo que solo se devuelvan las hojas de horas con los estados seleccionados. Cuando no se selecciona ningún estado, la exportación incluye hojas de horas de todos los estados.

• Configuración de hojas de horas: se resolvió un problema por el cual la fecha de inicio de hoja de horas configurada podía interpretarse de forma diferente entre zonas horarias, provocando que algunos usuarios vieran los periodos de hoja de horas comenzar más tarde de lo esperado. Los periodos de hoja de horas ahora se alinean correctamente con la fecha de inicio configurada.

• Financiero del proyecto: las Financial References ahora conservan las mayúsculas y minúsculas ingresadas por los usuarios al mostrarse en Fluid, en lugar de mostrarse en minúsculas.

• Manage Forecast: Fluid ahora puede configurarse para copiar filas de gasto real entre años financieros cuando no existe previsión, de modo que la cuadrícula Edit Financial Forecast permanezca consistente cuando los usuarios se mueven entre años. Cuando está habilitado, las filas de valores reales y sus Financial References permanecen visibles en las vistas del año fiscal correspondientes. Este comportamiento está deshabilitado de forma predeterminada y solo debería habilitarse cuando las organizaciones deseen que las filas exclusivamente reales sigan mostrándose en la cuadrícula de previsión.

• Manage Forecast: se resolvió un problema en la vista FYF donde la columna FYF Total solo incluía valores de previsión y no incluía valores reales. Los totales ahora se calculan correctamente en función de los valores mensuales mostrados en la cuadrícula.

• Carga de valores financieros reales: se resolvió un problema por el cual los valores de porcentaje de capitalización no se procesaban correctamente cuando se cargaban desde Excel como fórmulas o porcentajes con formato de texto, como 100%. Los porcentajes de capitalización ahora se gestionan correctamente ya sea que se carguen como fórmulas, valores con formato de porcentaje, o números.

• Capitalización: Fluid ahora puede configurarse para calcular la capitalización tan pronto como se añaden, actualizan o cargan previsiones o valores reales financieros en un proyecto elegible para capitalización. Esto brinda a los equipos valores de capitalización más oportunos cuando se necesitan, en lugar de esperar al cálculo nocturno estándar o activar manualmente un recálculo para el proyecto.

• Asignación de grupos SCIM: los administradores ahora pueden gestionar las asignaciones de grupos SCIM directamente en Fluid, navegando a Administration Console > User Management > SCIM Configuration. Los clientes que utilizan SCIM para la gestión de usuarios pueden asignar grupos de usuarios de Fluid a grupos SCIM, y cualquier asignación existente se muestra en la página de configuración.

• Carga de base de datos de recursos: se corrigió un problema por el cual la carga de nuevos recursos podía completar incorrectamente el campo License Number, lo que generaba conteos de recursos inexactos.

• Control de integración de DevOps y Jira: las integraciones de DevOps y Jira ahora pueden configurarse para retrasar la creación de elementos de trabajo vinculados hasta que una tarjeta de Fluid salga de la primera columna del flujo de trabajo.

  Desde el tablero correspondiente, vaya a Setup Integration, y luego abra la integración de Jira o DevOps. Habilite Skip First Column Create in Jira o Skip First Column Create in DevOps. Cuando está habilitado, las tarjetas creadas en la primera columna del flujo de trabajo no crearán de inmediato elementos de trabajo vinculados en Jira o DevOps. El elemento de trabajo vinculado solo se crea una vez que la tarjeta pasa a un estado posterior.

  Esto ayuda a los equipos a mantener los elementos en etapa inicial, en borrador o de admisión fuera de sus herramientas de entrega hasta que estén listos para avanzar.

• Marca en correos electrónicos: los correos electrónicos de notificación de Fluid ahora muestran el logotipo de la empresa cargado en General Settings en lugar del logotipo predeterminado de Fluid. Si no se ha cargado ningún logotipo de empresa, se seguirá utilizando el logotipo de Fluid.