Una lista de costes por unidad en Project Operations no es suficiente: la solución que ninguna IA nos propuso

Quienes llevamos años trabajando con Project Operations (PSA, Lite, Core... o como lo queráis llamar) sabemos que tiene limitaciones. No es objetivo de este post enumerarlas todas, pero hay una especialmente concreta: cómo gestiona los costes cuando el escenario deja de ser "de manual".

En proyectos sencillos, donde todo encaja en el estándar, PO cumple sin problema. Pero en escenarios empresariales reales —donde aparecen todas las necesidades de negocio de una compañía o de un grupo de empresas— es donde salen a la luz las carencias que tenemos que resolver de formas creativas.

El escenario:

Estas semanas, mi compañera Natalia Moreira y yo nos hemos enfrentado a un caso tan real como alejado del estándar de PO. Parecía sencillo, pero PO no lo cubre de base, así que tocaba "inventar" una solución.

Barajamos varias ideas hasta que, de repente, se encendió la bombilla (bueno, se le encendió a Natalia). Y lo probamos. Funciona, y lo hace de una forma tan sencilla y tan alineada con la filosofía de PO que hemos decidido compartir el problema y la solución con vosotros.

Para respetar la privacidad de los datos reales, hemos recreado el mismo escenario en nuestro propio entorno de pruebas, usando dos empresas ficticias —Cronus y Contoso, viva la originalidad 😉—):

• Contoso tiene proyectos y contratos, tanto de Precio Fijo como de T&M, y quiere empezar a usar recursos de otra unidad para determinados proyectos.
• Cronus, especialista en soluciones Microsoft, aporta esos recursos, que participarán en proyectos que vende y factura Contoso.
• Cada imputación de un recurso de Cronus en proyectos de Contoso debe generar coste y venta entre organizaciones (intercompany)

La limitación:

PO calcula el coste y la venta entre organizaciones como un dato real basado en el precio de coste que tiene el recurso de Cronus en la lista de costes de Contoso. El problema es que esa lista de costes es única, y solo puede haber una asociada a cada unidad organizativa para una misma fecha.

En la práctica: una UO, una lista de costes.

La necesidad:

El coste y la venta entre organizaciones no puede ser un valor único: cada proyecto o contrato tiene su propia negociación y sus propias tarifas.

El coste estándar del rol se queda corto.

Las ideas:

Como equipo, tocaba juntarse, buscar referencias, plantear el problema a la IA y explorar posibilidades. Dicho sea de paso: ninguna IA (ni Copilot, ni ChatGPT, ni Claude, ni Gemini) nos dio la solución. La IA es una herramienta maravillosa, pero en escenarios de negocio que requieren creatividad adaptada al estándar, los consultores y arquitectos todavía tenemos mucho que aportar.

Surgieron tres ideas, todas válidas, ninguna perfecta, todas ellas, además tanto propuestas como corroboradas con la IA, todas “podían funcionar”:

1. Una UO por cada variabilidad de tarifa, con su propia lista de costes asociada. Es la solución estándar, no requiere desarrollo, pero a futuro puede derivar en decenas o cientos de UOs y listas de costes que mantener. 
2. Una tabla "Intercompany Rates" asociada al contrato, con las tarifas por rol, corrigiendo después los datos reales mediante un plugin. Funciona, pero el coste operativo es alto: cada entrada de tiempo en un proyecto T&M genera 4 datos reales base, que habría que corregir uno a uno. Resultado: 12 registros por cada entrada. Con el tiempo, una tabla con millones de filas. 
3. La misma idea, pero usando los Detalles de línea del contrato en lugar de una tabla personalizada. Evita crear la tabla, pero el problema de fondo —y el volumen de datos— es idéntico.

El momento “eureka”:

Ya sin más alternativas a la vista, en una de esas sesiones de brainstorming que tienen algo de especial, Natalia lo soltó: "¿Y si metemos el contrato como variable en la lista de costes de Cronus, añadimos una nueva dimensión en los parámetros del sistema con prioridad absoluta, y hacemos que si hay contrato asociado arrastre ese coste a los datos reales, y si no, arrastre el coste base?"

Silencio. Miradas al techo. Consulta rápida a las cuatro IAs. Y al final, todos a una: "puede funcionar". Esa sensación, para quien se dedica a esto, no tiene precio.

Y vaya si funciona: sencilla, rápida, estándar. La solución era, simplemente, perfecta.

Además, ninguna IA nos la propuso, pero cuando se lo lanzamos la respuesta fue la misma en las 4 plataformas “Has dado con la solución mas estándar y más fiable y a nivel de negocio, mas operativa”.

Cómo implementarlo, paso a paso:

Aquí os desglosamos los pasos a seguir para que quede todavía más claro:

1. Necesitamos las dos UOs con sus listas de costes (en este caso, la lista de coste estándar). En un escenario real, aplicaríamos aquí el precio de coste intercompany más habitual, dejando las excepciones de cada contrato para los costes menos frecuentes.

1. Cada recurso debe tener, como mínimo, un rol predeterminado y estar asociado a su UO correspondiente (aunque en las imputaciones arrastrará el rol asignado como miembro del equipo del proyecto, que puede diferir de su rol predeterminado). 
2. Para guardar la variable del contrato en cada combinación unidad-rol-contrato, creamos un nuevo campo en la tabla "Precio de rol" (prefijo_nombreesquema; en nuestro caso, cp365_contract) y lo añadimos a la vista, al formulario de creación rápida y al formulario principal. Con esto ya podemos gestionar el precio de cada rol para la unidad específica de cada contrato.

Recordad: cuando un recurso participa en el proyecto/contrato de otra UO, se generan dos reales adicionales —el coste para la UO que vende el proyecto y la venta entre organizaciones—, que en el detalle financiero deberían coincidir, ya que lo que se factura es el acuerdo entre la UO que vende el proyecto y el cliente.

4. Creamos ese mismo campo, con el mismo nombre, en varias tablas más (no hace falta añadirlo a vistas ni formularios, solo que exista para poder arrastrar la variable a los datos reales): 

• Incremento de precio de rol
• Entrada de tiempo
• Real
• Línea de diario

5. Añadimos la dimensión en los parámetros de proyecto. En nuestro caso, solo queremos que aplique a costes.

5. Para que todo funcione, el contrato debe llegar informado desde la entrada de tiempo. Como probablemente no queréis que quien imputa rellene ese campo manualmente, lo más práctico es ocultarlo en el formulario y completarlo de forma desatendida (workflow en tiempo real, Power Automate en segundo plano, o un plugin).

5. Un ejemplo por tipología:

Escenario T&M, con dos casos posibles:

1. Un recurso de la unidad de contratación del proyecto imputa: se generan 2 reales (coste y ventas sin facturar). 
2. Un recurso de otra unidad imputa: se generan 4 reales (coste, venta sin facturar, coste de la unidad de dotación de recursos y venta entre organizaciones). Aquí es donde entra en juego nuestra solución: en lugar de arrastrar el coste base de la lista de costes de la unidad que vende el contrato, el sistema arrastra primero el coste asociado al contrato (nuestro campo personalizado), si está informado.

Imputamos 4 horas de trabajo, las enviamos, y el PM o los aprobadores del proyecto aprueban la imputación:

Una vez aprobada, el sistema genera los 4 datos reales:

El coste y la venta entre organizaciones arrastran el valor establecido para ese contrato en concreto, al tratarse de un precio de coste intercompany excepcional. Las ventas sin facturar reflejan el PVP que la UO que factura debe cobrar al cliente final, y el coste de la unidad de dotación de recursos, el coste/hora del recurso en la UO que le paga la nómina.

En los escenarios de Precio Fijo el planteamiento es idéntico, con la única diferencia de que el sistema no genera el dato real de "ventas sin facturar" (se factura por hitos, no por horas incurridas). El coste entre organizaciones funciona exactamente igual.

¡Y con esto, lo tenemos!

¿Te has encontrado con esta limitación en tus proyectos? Puedes contactar con nuestro equipo especializado en Microsoft Dynamics 365 para analizar cómo optimizar la arquitectura financiera de tu organización.