Cómo calcular la rentabilidad real de cada proyecto en Business Central (sin Excel)

Una pregunta que cualquier director financiero o de operaciones se hace cada mes: ¿cuál es el margen real de cada proyecto que tengo abierto? La respuesta debería ser un clic. En la mayoría de empresas que facturan por proyecto, en cambio, son 5-15 días de trabajo manual entre el cierre del proyecto y el dato fiable.

Esta guía cuenta cómo se calcula bien la rentabilidad de un proyecto dentro de Microsoft Dynamics 365 Business Central, sin necesidad de Excel paralelos, sin esperar al cierre mensual y sin discusiones sobre “qué coste cuenta”. Y cómo dvplanner — la extensión de planificación de Davisa — convierte ese cálculo en algo que el equipo de PMO ve en su pantalla cada mañana.

El problema real — el margen llega tarde

El síntoma con el que llaman las empresas suele ser este: el director de operaciones revisa los proyectos cada semana, pero los datos que tiene son siempre incompletos. Las horas imputadas tienen 1-2 semanas de retraso porque la gente las apunta los viernes en una hoja Excel. Las facturas de proveedor llegan cuando el proveedor las emite, no cuando el material se consumió. Los costes indirectos se imputan al cierre del mes. Cuando todo cuadra, el proyecto ya ha terminado — y a veces ha terminado en pérdidas.

Lo más doloroso de los proyectos que mueren con pérdidas no son las pérdidas en sí. Es que se podían haber evitado si alguien hubiera visto la desviación 3 semanas antes — cuando todavía había tiempo de re-negociar, optimizar o recortar.

Qué necesitas en BC para tener margen real

Business Central tiene casi todo lo necesario de fábrica. Las piezas mínimas son cinco:

1. Proyecto creado como Job en BC (no en una carpeta)

Cada proyecto facturable debe tener su Job en BC con:

• Cliente asociado.
• Manager responsable.
• Fecha de inicio / fin estimada.
• Estado (Quote / Planning / Open / Completed).
• Un Job Task por cada partida con presupuesto independiente.

Si el proyecto vive solo en una carpeta de OneDrive con un Excel dentro, BC no puede calcular nada. Crear el Job correctamente es el paso 0, y muchas empresas se lo saltan “porque es papeleo”.

2. Presupuesto inicial por tarea (Job Task Line tipo Budget)

Cada tarea del job tiene sus líneas presupuestadas:

• Horas de cada rol (Senior, Junior, Project Manager).
• Materiales previstos.
• Subcontratas previstas.
• Gastos generales asignados (viajes, dietas).

El presupuesto se carga al firmar el contrato con el cliente. No al cabo de 3 semanas, no “cuando tengamos tiempo”. Sin presupuesto, no hay desviación posible — porque no hay referencia.

3. Imputación de horas en BC (Resource Time Sheet)

Las horas trabajadas deben llegar a BC el día que se trabajan, no el viernes ni a final de mes. BC tiene Time Sheets nativos, aprobables por el manager, vinculados a job y task.

Esta es la pieza que más empresas hacen mal: el equipo imputa en Excel o en una herramienta paralela y “alguien” lo vuelca a BC al final. Mientras esa hora no está en BC, el coste del proyecto está mal calculado.

4. Compras y subcontratas asociadas al job (Purchase Line con Job No.)

Cuando lanzas un pedido de compra para el proyecto, el campo Job No. en la línea de compra debe estar relleno. No al recibir la factura — al lanzar el pedido.

Esto convierte el pedido en un compromiso de coste: BC sabe que hay 3.500 € comprometidos a este job, aunque la factura del proveedor llegue en 45 días. Sin esto, el coste del proyecto solo aparece cuando facturan — demasiado tarde.

5. Tarifas internas reales por recurso

La Resource Card de BC debe tener la tarifa interna real, no la contractual al cliente. Tarifa interna = coste salarial + Seguridad Social + indirectos imputados.

Una pyme española típica:

• Salario bruto desarrollador senior: 50.000 €/año.
• Seguridad Social (33%): 16.500 €.
• Indirectos asignados (oficina, IT, formación, vacaciones, paro técnico): 20-30% sobre coste laboral total.
• Coste hora real: ~50 €/hora.

Si en BC pones la tarifa de venta (90 €/h) como tarifa interna, el margen es mentira. Es uno de los errores más extendidos.

El cálculo del margen, paso a paso

Con las 5 piezas anteriores en su sitio, BC calcula el margen así (simplificado):

COSTE TOTAL DEL JOB =
    Σ (Horas imputadas × Tarifa interna del recurso)
  + Σ (Compras a proveedor asociadas al job)
  + Σ (Subcontratas asociadas al job)
  + Σ (Gastos generales imputados al job)

FACTURACIÓN TOTAL = Σ Facturas al cliente del job

MARGEN BRUTO = FACTURACIÓN - COSTE TOTAL
MARGEN %    = MARGEN BRUTO / FACTURACIÓN × 100

BC ofrece este cálculo en directo en el Job Card, en los informes estándar Job Profitability y Job WIP - To Recognize, y en Power BI vía el conector estándar.

El problema no es la fórmula. El problema es alimentar las variables:

• Horas imputadas tarde → coste falsamente bajo.
• Compras sin job number → coste falsamente bajo.
• Tarifa interna inflada → margen falsamente alto.
• Tarifa interna correcta pero olvidamos indirectos → margen falsamente alto.

Dónde dvplanner añade valor encima

Business Central, bien configurado, calcula el margen. Lo que no hace de fábrica son tres cosas que sí necesita un PMO:

A) Visión cross-proyecto en tiempo real

BC muestra el margen de un job en su Job Card. Para ver los 40 proyectos abiertos a la vez — cuáles están en márgenes sanos, cuáles se desvían, cuáles van retrasados — hace falta Power BI + informes. dvplanner trae el dashboard cross-proyecto ya construido sobre el modelo BC.

B) Alertas de desviación cuando todavía hay margen

¿Qué pasa si la tarea X se está comiendo el doble de horas presupuestadas, pero el job todavía está dentro de margen global? BC no avisa. dvplanner sí — alertas por partida cuando la desviación supera un umbral configurable (ej. 20%), aunque el total siga sano.

C) Imputación fácil = imputación a tiempo

El mayor enemigo del cálculo correcto es que la gente no imputa, porque hacerlo en BC nativo es funcional pero no rápido. dvplanner trae una interfaz móvil/web ligera para que cada persona impute sus horas en 30 segundos, desde el móvil, mientras se mueve. Resultado: las horas llegan el mismo día. El margen es real desde minuto 1.

Errores típicos que invalidan el cálculo

He visto los mismos errores en empresas distintas. Si estás pensando en limpiar tu modelo de datos para que el margen sea fiable, evita estos:

1. Tarifa contractual = tarifa interna: la tarifa que cobras al cliente NO es lo que te cuesta esa hora. Diferencialas en BC. Si no, todos tus proyectos parecen rentables.
2. Imputación al final de mes: convierte el cálculo en “post-mortem”. El margen del mes 3 lo ves en el cierre del mes 4. Demasiado tarde para reaccionar.
3. Compras sin Job No.: la factura del proveedor entra a una cuenta genérica de coste, no al proyecto. Margen falso.
4. Indirectos no imputados: la oficina, el IT, los servicios generales no son gratis. O los repartes (cuenta de coste indirecto) o los incluyes en la tarifa interna. Olvidarlos = -10 a -15 puntos de margen real.
5. Job en BC pero presupuesto en Excel: BC no puede comparar contra “el Excel que está en una carpeta”. Sin presupuesto en Job Task Lines, no hay desviación.
6. Cambios de alcance sin documentar en BC: el cliente pidió +20 horas en la semana 4, lo aceptaste por email, pero el presupuesto del job sigue siendo el original. La desviación de las +20 horas la verás como mala — cuando en realidad fue alcance ampliado.

El caso de uso típico — distribución de tiempos antes y después

Cliente Davisa: consultora de servicios profesionales, 80 personas, 60 jobs abiertos en paralelo. Antes de dvplanner (con BC nativo + Excel paralelos):

• Imputación de horas: viernes tarde, todo el equipo, en una hoja compartida. Se volcaba a BC los lunes.
• Visibilidad del margen: el director financiero lo veía en el cierre mensual, día 15 del mes siguiente.
• Alertas de desviación: ninguna. Se descubrían en la reunión de cierre del proyecto.
• Tiempo medio entre evento (desviación) y reacción: 18-25 días.

Después de implantar dvplanner (3 semanas de proyecto):

• Imputación de horas: cada persona, cada día, en 30 segundos desde móvil.
• Visibilidad del margen: dashboard en directo. El director financiero entra al sistema y lo ve.
• Alertas de desviación: automáticas cuando una partida se desvía >20%.
• Tiempo medio evento-reacción: 1-3 días.

Resultado a 12 meses: el margen consolidado de la consultora subió +2.4 puntos. No por hacer más, por reaccionar antes a las desviaciones.

Cómo arrancar — el camino corto

Si tu empresa ya tiene Business Central y quieres tener margen real por proyecto:

1. Semana 1: auditoría de tu modelo. ¿Tienes Jobs creados? ¿Presupuesto en Job Task Lines? ¿Tarifas internas reales? ¿Time Sheets en uso? Davisa lo hace gratis como parte de la fase de diagnóstico.
2. Semanas 2-3: limpieza del modelo + carga de datos faltantes. Si la tarifa interna estaba mal, se ajusta. Si las compras no estaban asociadas a job, se asocian (al menos las nuevas).
3. Semanas 3-5: implantación de dvplanner sobre el BC limpio. Dashboards, alertas, interfaz móvil de imputación, formación al PMO y al equipo.
4. A partir de ahí: el margen es un dato vivo en tu BC. No un cálculo manual de fin de mes.

Cierre — el margen no es un cálculo, es una disciplina

La rentabilidad real de un proyecto no se “calcula al final” — se construye mientras el proyecto está abierto, alimentando con datos limpios el modelo del ERP día a día.

Business Central tiene todo lo necesario. dvplanner añade lo que falta para que el PMO lo vea, lo entienda y reaccione a tiempo. La combinación de los dos es lo que convierte el margen en una herramienta de gestión, no en una métrica post-mortem.

¿Quieres una sesión de 30 minutos para revisar cómo está tu BC hoy y qué falta para que el margen sea real? Habla con un asesor de Davisa — sin compromiso, sin venderte nada que no necesites.