Migración de recursos: planificación de capacidad desde Microsoft Project

El valor de Project Server, para las PMO que lo gestionan bien, rara vez son los planes de proyecto en sí. Era la capa operativa de debajo: un único pool de recursos de la organización del que se nutría cada proyecto, partes de horas con costes que alimentaban la facturación y el reconocimiento de ingresos, excepciones de calendario que se propagaban solas y vistas entre proyectos con las que los gestores de recursos decidían cada semana la asignación de personas sobre datos reales. Esa capa operativa es lo que está en juego. Los planes se migran. La capa operativa, a menudo no.

Tres modos de fallo aparecen una y otra vez cuando las PMO subestiman esto:

• La trampa de «ya añadiremos los recursos después». Un equipo migra los planes limpiamente y deja el pool de recursos para el sprint siguiente. Cuando llega el momento, los responsables de cada proyecto ya han creado recursos duplicados en sus proyectos, y el gestor de recursos ha perdido la fuente única de verdad que hacía funcionar las vistas de capacidad entre proyectos.
• La trampa de «las tarifas de coste no son críticas para el arranque». Las tarifas estándar se aplazan a una limpieza en la fase 2. Dos meses después, Finanzas descubre que su cierre mensual necesita datos de partes de horas con costes que ya no existen en la nueva plataforma, porque las tarifas no estaban cargadas al registrar las horas. Los datos no se pueden reconstruir a posteriori; el reconocimiento de ingresos se detiene.
• La trampa de «Planner Premium servirá». Una PMO da por hecho que el producto en la nube de Microsoft cubre los mismos casos de uso. Para el modelado de recursos, no los cubre. Planner Premium no trae pool de recursos de la organización, ni partes de horas con costes, ni vista de recursos entre proyectos. Descubrirlo después de migrar es demasiado tarde.

La razón estructural de los tres: el modelo de recursos es la parte de Project Server menos visible en una demo de producto rápida y la menos cubierta en las listas de comparación de proveedores. Los planes, los Gantt y los paneles lucen bien en una demo. Los pools de recursos de la organización, no. Por eso los compradores dan poco peso a la cobertura del modelo de recursos al elegir plataforma y descubren el hueco en producción. Esta guía presenta primero el modelo, antes que la táctica de migración, partiendo de que la decisión más importante es qué plataforma de destino elige.

Antes de decidir qué migrar, haga inventario de lo que tiene. El modelo de recursos de Project Server tiene seis capas, y cada una se migra de forma distinta:

No todas las PMO usan todas las capas. La pregunta correcta del inventario es «¿en cuáles de estas se apoya de verdad nuestro equipo para decidir?». Si no usa partes de horas con costes, la capa de tablas de tarifas es decorativa; puede prescindir de ella sin consecuencias. Si no usa genéricos para modelar la demanda, puede fusionarlos. Si los usa para eso, esa capacidad no es negociable en la plataforma de destino.

Haga el inventario antes de comparar plataformas. Su resultado es una lista de capacidades imprescindibles para la plataforma de destino, y esa lista da forma al resto de la migración. La sección siguiente supone que ya tiene esa lista.

Las comparaciones de plataformas se estrechan cuando filtra por cobertura del modelo de recursos. Este es el panorama honesto, ordenado por las seis capas de arriba. Sí, parcial o no para cada una:

El producto en la nube de Microsoft (Planner Premium / Project for the Web, el mismo producto con distintas etiquetas de SKU) deja fuera casi todo el modelo de recursos. Es una decisión deliberada de posicionamiento: es una herramienta de tareas de equipo con una capa de proyecto, no una plataforma para PMO. Las PMO que usan en serio el modelo de recursos de Project Server no pueden sustituirlo por Planner Premium sin perder capacidades importantes.

El módulo Resource Management de Smartsheet y Workfront conservan ambos el concepto de pool de la organización. Difieren en los detalles: Smartsheet RM es un SKU aparte y añade un coste notable por puesto; el pool de Workfront es sólido, pero su precio por puesto es el más alto de los cuatro. Onplana no tiene un pool de recursos aparte: cada persona es un miembro de la organización, y su modelo de recursos es la capacidad semanal de esa persona en todos los proyectos (desde el plan Professional), tarifas en tres niveles (persona, rol, valor predeterminado de la organización) y calendarios laborales con excepciones con nombre, sin complementos de pago. No tiene recursos genéricos, ni calendarios por persona, ni RBS formal. El precio empieza en 12 dólares por puesto al mes (Professional). La comparación honesta con Planner Premium está en nuestra página de comparación con Planner.

Hay otra dimensión que cuesta poner en una tabla: la calidad de la vista de capacidad entre proyectos varía mucho entre plataformas incluso cuando la función básica existe. Algunas solo muestran asignaciones directas de tareas; otras incluyen agregados de subproyectos; otras, la asignación de marcadores genéricos. Si su gestor de recursos decide cada semana la asignación de personas con esta vista, compárela lado a lado durante la evaluación con los 25 recursos con más horas asignadas.

Antes de exportar nada, haga un inventario completo del modelo de recursos. Es un inventario distinto del de la lista de proyectos: aquel cataloga proyectos; este cataloga la capa de recursos que hay debajo. El entregable es un Informe de Preparación de la Migración de Recursos que enumera cada elemento de recursos, dónde está hoy, adónde va y quién se encarga del traslado.

1. Lista de recursos con atributos. Exporte el pool completo de recursos de la organización con nombre, tipo (nominal/genérico/coste), correo (para los nominales), unidades máximas, tarifa estándar, rol/cargo y ruta en la RBS. El endpoint OData /Resources es la fuente de referencia; la Reporting Database tiene más campos derivados, pero solo en Project Server local.
2. Tablas de tarifas de coste. Microsoft Project admite hasta 5 tarifas de coste por recurso (tarifa A a tarifa E) con rangos de fechas de vigencia. Exporte cada nivel de tarifa y cada fila de fecha de vigencia. Si su PMO solo usa la tarifa A puede ignorar B–E, pero compruebe que de verdad es así antes de suponerlo.
3. Excepciones de calendario. Para cada recurso, exporte la lista de excepciones de calendario con su nombre, rango de fechas y horario alterado. Si su plataforma de destino no conserva las excepciones con nombre, guarde los nombres en un CSV complementario para que la razón («Semana del congreso», «Cierre por vacaciones») se mantenga.
4. Jerarquía RBS. Exporte la estructura de desglose de recursos: cada nodo, los vínculos padre-hijo y los recursos asignados a cada nodo. La jerarquía es lo que permite a los gestores de recursos filtrar las vistas de capacidad por su estructura de reporte.
5. Asignaciones activas. Tome una instantánea de cada asignación activa en cada proyecto activo: qué recurso, qué proyecto, qué tarea, horas asignadas, horas reales, comienzo y fin programados. Es la base de la validación; después de migrar comparará la asignación en origen y destino.
6. Campos personalizados de recursos. Si su PMO definió Enterprise Custom Fields en los recursos (nivel de habilitación de seguridad, marca de facturable, tipo de contrato), expórtelos junto con la lista de recursos. Algunas plataformas de destino los modelarán como campos integrados, otras como campos personalizados y otras no los admitirán; eso decide después el mapeo de campos.

El Informe de Preparación terminado es la base del resto de la migración. Para comprobar la calidad de la exportación antes de comprometerse, pase un pool de muestra por la herramienta de vista previa de migración: suba una porción representativa del pool de recursos y vea exactamente qué campos, tarifas y excepciones se transfieren limpiamente.

Cinco fases, cada una con un entregable y un punto de control de continuar o no. El tiempo total suele ser de 3–5 semanas para un pool de 100–250 recursos, más si tiene tablas de tarifas de coste muy personalizadas o una RBS grande.

Fase 1: Inventario y decisiones (1 semana)

Complete el inventario previo de arriba y luego decida la plataforma según qué capas del modelo de recursos no son negociables para su equipo. Documente la decisión con sus razones; es la sección que releerá cuando alguien pregunte por qué la plataforma elegida no tiene la función X.

• Hacer el inventario sobre el inquilino en uso
• Puntuar cada plataforma de destino frente a su lista de capas imprescindibles
• Elegir el destino y documentar las razones
• Obtener la aprobación de la dirección de la PMO para la plataforma elegida

Punto de control: Informe de Preparación firmado; plataforma de destino elegida.

Fase 2: Exportar el pool (2–3 días)

Exporte desde Project Server mientras siga en marcha y compruebe después que la exportación contiene cada capa de la lista. No confíe en las exportaciones de archivos .mpp para el pool de recursos; solo llevan asignaciones de recursos locales del proyecto, no el pool de la organización con sus tarifas, calendarios y RBS.

• La lista de recursos, desde /Resources
• Las excepciones de calendario, desde /Resources/Calendars
• Las tablas de tarifas de coste (o la Reporting DB, en local)
• La RBS, desde los endpoints de la API SOAP, que no tienen equivalente en OData
• Las asignaciones activas, desde /Assignments
• Recuentos que coincidan con el Informe de Preparación

Punto de control: el recuento exportado coincide con el del Informe de Preparación en cada capa.

Fase 3: Remodelar en el destino (3–7 días)

Importe el pool en la plataforma de destino y resuelva capa a capa los huecos de traslado que mostró la comparación de plataformas. Los genéricos que no se trasladan se remodelan como marcadores nominales. Los nombres de excepciones de calendario que no se trasladan se archivan. Los campos personalizados de recursos se mapean a campos integrados o a definiciones de campos personalizados en el destino.

• Importar la lista de recursos (importación masiva o API del destino)
• Volver a crear la jerarquía RBS y asignar los recursos a sus nodos
• Cargar las tarifas estándar y las tablas de tarifas de coste antes de cargar ninguna asignación
• Aplicar las excepciones de calendario por recurso
• Trasladar los recursos genéricos según el modelo de la plataforma
• Mapear los campos personalizados de recursos

Punto de control: recuento del pool, jerarquía RBS y recuento de tablas de tarifas coinciden con el origen.

Fase 4: Asignar y validar (1 semana)

Migre las asignaciones de tareas proyecto a proyecto, en oleadas agrupadas por equipo responsable. Tras cada oleada, el equipo receptor valida la asignación en destino frente al origen para sus proyectos en un plazo de 48 horas. No avance hasta que la oleada valide limpia; perseguir desviaciones de asignación acumuladas en muchos proyectos es mucho más difícil que corregirlas proyecto a proyecto.

• Migrar las asignaciones en oleadas de 10–25 proyectos
• Diferencia de asignación por recurso y proyecto: origen frente a destino
• Investigar cualquier variación > 5%
• Conciliar los cálculos de partes de horas con costes sobre una muestra de partes pasados

Punto de control: diferencia de asignación por recurso < 5% en todos los proyectos.

Fase 5: Vistas de capacidad y conciliación (1 semana)

Vuelva a crear las vistas de capacidad que los gestores de recursos usan de verdad y ejecútelas en paralelo con Project Server durante al menos 5 días laborables. Los informes diarios de diferencias señalan cada punto en que el cálculo de capacidad de la nueva plataforma difiere del de la antigua. Investigue cada diferencia. Documente las diferencias reales como limitaciones conocidas.

• Reconstruir las 5 vistas de capacidad principales en el destino
• Generar informes diarios de diferencias para los 25 recursos con más horas asignadas
• Investigar variaciones > 5%; documentar las diferencias reales de plataforma
• Formar a los gestores de recursos en la nueva interfaz de vistas de capacidad
• Cambio: el destino pasa a ser la fuente de verdad, Project Server queda en solo lectura

Punto de control: 5 días laborables seguidos de informes diarios de diferencias limpios; los gestores de recursos aprueban la nueva interfaz de vistas de capacidad.

Los cinco modos de fallo del modelo de recursos que aparecen con más frecuencia, con la prevención de cada uno:

El patrón de los cinco: cada uno es una decisión del tipo «ya lo veremos después» que sale barata en el momento y cara en producción. El trabajo de conciliación es uno de los costes que más se subestiman en los presupuestos iniciales; en la calculadora de costes de migración entra en operación en paralelo.

La fase de validación tiene tres comprobaciones, y cada una produce una evidencia. Archívelas con el Informe de Preparación; juntas forman el rastro de auditoría de la migración.

1. Conciliación de la asignación por recurso. Para los 25 recursos con más horas asignadas en los próximos 90 días, compare la asignación en origen y destino. Tolerancia: ±5%. Una variación mayor significa que la migración de asignaciones perdió datos o que el cálculo de capacidad del destino difiere estructuralmente del de Project Server. Ambas cosas deben investigarse. Evidencia: un informe de diferencias por recurso.
2. Conciliación de una muestra de partes de horas con costes. Elija los 10 partes cerrados más recientes de 5 recursos distintos. Vuelva a calcular el coste en el destino con las mismas entradas de tiempo. Tolerancia: ±1% (es dinero; la tolerancia es más estricta que la de asignación). Una variación > 1% indica una tarifa errónea, una excepción de calendario perdida o ambas. Evidencia: los cálculos de coste lado a lado.
3. Paridad de las vistas de capacidad entre proyectos. Reproduzca las 3 vistas de capacidad que los gestores de recursos usan más. Compárelas con la última ejecución de Project Server para el mismo periodo. Es de esperar que las dos vistas clasifiquen la asignación de forma distinta (directa o de subproyecto, nominal o genérica). Documéntelo como diferencias conocidas de plataforma en el manual posterior a la migración. Evidencia: capturas lado a lado con las diferencias documentadas.

El resultado de la fase de validación es un Informe de Resultado de la Migración con lo que se migró, lo que no y lo que queda abierto. Junto con el Informe de Preparación de la fase 1, los dos documentan el rastro de auditoría completo.

La PMO es responsable del manual de migración, pero el modelo de recursos tiene consecuencias que los equipos de finanzas descubren después del cambio si nadie las plantea antes. Tres patrones aparecen en toda migración con recursos con costes, y cada uno golpea de forma distinta a los problemas del lado de la PMO.

Tres conceptos de tarifa que se confunden

Project Server lleva tres tarifas distintas por recurso que suenan parecido y NO son intercambiables: la tarifa estándar (el coste de una hora interna para modelar la asignación, a menudo el coste laboral completo), la tarifa de coste (la que se usa para calcular el coste contable de un parte de horas, a veces dividida en las tablas de tarifas A a E para distintos tipos de actividad) y la tarifa de facturación (la que se cobra a un cliente por las horas facturables de un encargo). Algunas PMO usan una tarifa para los tres conceptos; otras, tarifas distintas por concepto; otras, niveles de tablas de tarifas dentro de cada concepto.

Antes de exportar, pregunte a finanzas qué conceptos de tarifa usan de verdad, qué niveles de tablas corresponden a qué actividades y qué campos de la plataforma de destino llena cada tarifa. La exportación es una fila por tarifa y recurso; la importación es una decisión de mapeo que determina si los informes de reconocimiento de ingresos del próximo trimestre cuadran. Un error común y recuperable es cargar las tarifas de facturación en el campo de tarifa de coste. Los partes con costes se calculan entonces con la tarifa de facturación, los informes de resultados muestran costes inflados y la solución es volver a exportar y volver a cargar. Un error peor y más difícil de corregir es cargar las tarifas de coste en el campo de tarifa de facturación. Las facturas emitidas con la tarifa equivocada deben reemitirse, y la conversación de corrección con el cliente no sale gratis.

Las reglas de capitalización no se trasladan solas

Las PMO de organizaciones reguladas o con mucha inversión suelen tener políticas de capitalización de mano de obra que dicen «las horas de ingeniería en proyectos capitalizables se acumulan en un activo del balance en lugar de en gasto». En Project Server estas reglas suelen vivir como vistas o informes construidos sobre el feed OData, a veces con una marca por proyecto y otra por tarea. Nada de esa infraestructura se migra solo. Las marcas se exportan (valores de campos personalizados); las vistas y los informes, no. Finanzas tiene que reconstruir desde cero los informes de capitalización en la nueva plataforma, sobre los mismos datos marcados.

El riesgo es un trimestre silencioso en el que los informes de capitalización no se reconstruyeron, horas que debían capitalizarse se llevaron a gasto y el periodo cierra con cifras erróneas. Los errores materiales aquí son una observación de control interno. Pida a finanzas que plantee la reconstrucción de la capitalización como una línea de trabajo paralela a la migración, no como un seguimiento, y condicione el cambio a al menos un periodo cerrado de informes de capitalización lado a lado que cuadren.

Los informes de utilización facturable necesitan una configuración explícita

Las PMO de servicios profesionales viven de la utilización facturable (horas facturables divididas entre horas pagadas, por recurso y en total). Project Server la obtiene combinando los datos de partes de horas con una marca de «facturable» en la asignación o en la tarea. La marca se exporta limpiamente; el informe, no. Como muestra la matriz de comparación de arriba, el soporte de informes nativos de utilización facturable varía según la plataforma de destino. Onplana, Smartsheet RM y Workfront ofrecen el informe como pieza de primer nivel; Planner Premium de Microsoft no tiene concepto de facturable.

Para las PMO que migran a una plataforma que sí admite la utilización facturable, condicione el cambio a un informe lado a lado de las últimas 4 semanas que cuadre dentro de ±2%. Cualquier variación mayor apunta a un error de mapeo de tarifas, una marca de facturable que falta o una asignación que no se migró. Para las PMO cuya plataforma de destino no admite la utilización facturable de forma nativa, prevean llevar la instantánea OData a una herramienta de BI posterior (Power BI, Looker, Sigma) y reconstruir allí el informe. En ambos casos, finanzas debería aprobar la exactitud del informe antes de apagar la plataforma antigua. Si no, el primer cierre de mes en la nueva plataforma es cuando aparece el hueco, que es el peor momento posible.

Por qué finanzas tiene que estar en la sala antes del cambio

En toda migración en la que finanzas entró tarde se repiten los mismos tres problemas: hay que rehacer los mapeos de tarifas porque finanzas no compartía la lectura de la PMO sobre qué tarifa es cuál; los informes de capitalización no se reconstruyeron y el primer cierre trimestral en la nueva plataforma reportó mal la mano de obra capitalizada; la variación de utilización facturable superó la tolerancia de la PMO porque finanzas aplica otras reglas. Ninguno es un problema de plataforma; todos son fallos de coordinación. La solución es barata: incluya a finanzas como aprobador con nombre en la fase 1 (inventario) y la fase 4 (asignar y validar). Su aprobación cierra el círculo del mapeo de tarifas, los informes de capitalización y la tolerancia de utilización facturable. Sin ella, la PMO entrega la migración y finanzas descubre el coste semanas después, casi siempre en un cierre de mes y casi nunca con un calendario que permita rehacerlo con calma.

La migración es el detonante; la pregunta a largo plazo es si la práctica de planificación de capacidad de su PMO sigue funcionando en la nueva plataforma. Cuatro hábitos distinguen a los equipos que mantienen el rigor de los que se desvían:

• Fuente única de verdad, aplicada. El pool de recursos de la organización es la referencia; crear recursos locales en un proyecto es un indicador temprano de desviación. Algunas plataformas permiten bloquear el permiso de creación por proyecto. Úselo si está disponible; si no, haga una revisión semanal que compare las listas de recursos de cada proyecto con el pool de la organización.
• Revisión trimestral de tarifas. Las tarifas estándar que pasan 12+ meses sin revisarse se alejan del coste laboral completo real. Los partes de horas con costes se alejan entonces de la realidad financiera. Fije un ritmo trimestral para revisar las tablas de tarifas y volver a fijarlas.
• Disciplina con las excepciones con nombre. Las excepciones de calendario se acumulan en silencio. Un recurso con 30 excepciones con nombre en 3 años es normal; sin un ritmo de revisión, las excepciones se fosilizan. Cada año, revise el número de excepciones por recurso y elimine todo lo que supere el periodo de conservación de la política.
• Evolución de la RBS. La jerarquía de reporte que era correcta al migrar se queda anticuada a medida que la organización se reorganiza. Planifique una revisión de la RBS cada 6 meses dentro del ciclo general de revisión del diseño organizativo, para que el corte de las vistas de capacidad siga teniendo sentido.

Las preguntas que las PMO hacen con más frecuencia sobre la migración del modelo de recursos. El esquema FAQPage completo va en los datos estructurados de este artículo, para que estas preguntas aparezcan en la función «Otras preguntas de los usuarios» de Google.

Expand