Para los contratistas en los Emiratos Árabes Unidos (EAU), controlar múltiples proyectos requiere más que un tablero consolidado. Requiere un modelo operativo compartido que conecte el alcance, el presupuesto, el cronograma, los recursos, los compromisos y el desempeño real de cada proyecto. Un ERP de construcción debe preservar los controles de cada proyecto y de cada entidad legal, a la vez que ofrece a la dirección visibilidad sobre toda la cartera. El objetivo es coordinar las compras, asignar recursos, identificar la exposición de costos y respaldar decisiones oportunas, sin obligar a todos los proyectos a adoptar una estructura de ejecución idéntica.
Considere un contratista que ejecuta un desarrollo residencial en Dubái, un paquete de infraestructura en Abu Dabi y obras de servicios públicos en Sharjah.
Cada proyecto tiene su propio cliente, programa, condiciones comerciales y prioridades de entrega. Sin embargo, los proyectos pueden competir por la misma capacidad de compras, los mismos proveedores, equipos, mano de obra especializada y capital de trabajo.
Una decisión que beneficia a una obra puede crear un problema en otra.
Trasladar una excavadora puede resolver una necesidad urgente, pero retrasar otro proyecto. Consolidar las compras de materiales puede mejorar el precio negociado, pero aumentar las necesidades de almacenamiento. Acelerar la construcción puede mejorar el avance físico, pero incrementar la necesidad inmediata de efectivo.
En mi opinión, el control de construcción multiproyecto no es simplemente la suma de los informes de cada proyecto.
Es la capacidad de comprender —y gobernar— las relaciones entre los proyectos.
1. Por qué importa el contexto de los EAU
La escala y la variedad del desarrollo en los EAU hacen de esta una cuestión operativa importante.
En su anuncio de aprobaciones de desarrollo de 2025, publicado el 12 de marzo de 2026, el Departamento de Municipios y Transporte de Abu Dabi informó aprobaciones que abarcan casi 75 millones de metros cuadrados de superficie bruta construida. Se trata de aprobaciones de desarrollo, no de construcción terminada ni de ingresos de contratistas.
Por su parte, el anuncio de la Línea Azul del Metro de Dubái de la Autoridad de Carreteras y Transporte, fechado el 9 de junio de 2025, describió un proyecto de 30 kilómetros que añade 14 estaciones. Ilustra un entorno de ejecución distinto: infraestructura de transporte con múltiples ubicaciones, interfaces y paquetes de trabajo.
Estos ejemplos no deben combinarse para inventar una estimación del tamaño del mercado. Su relevancia es operativa: los contratistas necesitan sistemas capaces de gestionar distintos tipos de proyectos dentro de un marco de gestión coherente.
Ese marco también debe contemplar requisitos específicos de los EAU, como los procesos de pago a la fuerza laboral, las restricciones de trabajo en verano y la introducción gradual de la facturación electrónica.
El requisito no es simplemente un ERP disponible en los EAU. Es un modelo operativo que se ajuste a la forma en que el contratista ejecuta proyectos en los EAU.
2. ¿Qué significa realmente “una sola plataforma operativa”?
Una sola plataforma operativa no debería significar un enorme archivo de proyecto único.
Tampoco debería significar que todos los usuarios puedan acceder a la información financiera de todas las filiales.
Yo la definiría mediante tres niveles conectados.
- Una base empresarial común. Clasificaciones de recursos compartidas, registros de proveedores, convenciones de códigos de costo, reglas documentales y definiciones de reportes.
- Controles de proyecto separados. Cada proyecto conserva su propio alcance, versiones de presupuesto, cronograma, contratos, límites de aprobación, pronósticos y responsabilidades.
- Coordinación a nivel de cartera. La dirección autorizada puede examinar la demanda combinada de recursos, la exposición en compras, las necesidades de efectivo y las excepciones de los proyectos.
DANAOS Insights analiza esta distinción en ERP multiempresa para organizaciones basadas en proyectos: la visibilidad centralizada debe coexistir con el control operativo y financiero a nivel de cada entidad.
El principio de diseño es sencillo:
Estandarice la información necesaria para el control. Preserve las diferencias necesarias para la ejecución.
Por ejemplo, un proyecto de edificación y un proyecto vial pueden compartir una clasificación corporativa para los costos de equipos sin utilizar la misma Estructura de Desglose del Trabajo (WBS) ni los mismos supuestos de productividad.
Un código de costo común no justifica un rendimiento de producción común.
3. Conecte el alcance, el cronograma y la estructura de costos de cada proyecto
Antes de consolidar la información, el contratista necesita una base confiable a nivel de proyecto.
El enfoque de DANAOS conecta:
BoQ ↔ WBS ↔ Cost Codes
- El presupuesto de cantidades (BoQ) —o una estructura equivalente de alcance cuantificado— proporciona las partidas de trabajo y las cantidades con respecto a las cuales se pueden analizar los recursos y los costos.
- La Estructura de Desglose del Trabajo (WBS) organiza el alcance del proyecto. Sus actividades, dependencias y calendarios asociados establecen el cronograma de ejecución.
- Los códigos de costo (Cost Codes) proporcionan la clasificación interna utilizada para acumular y analizar los costos del proyecto.
La relación se explica en BoQ, WBS y códigos de costo: cómo conectar alcance, cronograma y costo. ProjectVIEW ERP está diseñado para asociar estas dimensiones en lugar de tratarlas como estructuras de reporte sin relación entre sí.
Para un contratista multiproyecto, recomiendo extender ese principio mediante un mapeo corporativo gobernado.
Una transacción de obra debe identificar su proyecto y el paquete de trabajo correspondiente, conservando a la vez las clasificaciones necesarias para los reportes del grupo. Las reglas de mapeo también deben evitar que la misma cantidad o el mismo costo se contabilicen repetidamente cuando las relaciones abarcan varias actividades o categorías de reporte.
Así, el contratista puede plantear dos preguntas distintas sin perder la conexión entre ellas:
“¿Qué está ocurriendo en este paquete de trabajo?”
“¿Dónde aparece el mismo tipo de exposición en otras partes de la empresa?”
Para más contexto, consulte líneas base integradas de desempeño del proyecto.
4. Centralice las compras sin perder la responsabilidad del proyecto
Un equipo de compras central necesita comprender algo más que la cantidad combinada solicitada por varias obras.
Debe conocer la especificación, el requerimiento aprobado, el inventario disponible, la asignación al proyecto y la fecha de entrega requerida.
Considere tres proyectos que solicitan materiales similares.
Antes de emitir una nueva orden de compra, el proceso operativo propuesto debe determinar si ya existe inventario adecuado, si está reservado y si un traslado afectaría al proyecto que actualmente lo tiene.
Solo entonces el área de compras debe decidir si traslada, compra por separado o consolida el requerimiento.
DANAOS Insights describe esta secuencia en desafíos de las compras basadas en proyectos. Su flujo de trabajo publicado conecta las solicitudes de obra con el contexto presupuestario, la disponibilidad de inventario, la reasignación de materiales y las compras.
El requisito de control consiste en preservar el destino y la responsabilidad comercial a lo largo de todo el proceso.
Una solicitud de cotización consolidada no debe borrar las asignaciones a los proyectos. Un acuerdo marco no debe eliminar los controles de fechas de entrega. Un traslado de inventario debe conservar su trazabilidad de autorización y valoración.
Los traslados entre entidades legales distintas también deben diseñarse junto con el equipo de finanzas, y no tratarse automáticamente como movimientos ordinarios entre almacenes.
Centralice las decisiones de compra cuando resulte útil. Mantenga la responsabilidad vinculada al proyecto y a la entidad que consumen el recurso.
5. Gestione la mano de obra y los equipos como recursos compartidos, pero limitados
La planificación de recursos de la cartera debe distinguir entre disponibilidad e idoneidad.
Una máquina puede estar físicamente disponible pero comprometida con otro proyecto. Una cuadrilla puede estar libre la próxima semana pero carecer de la especialización requerida. Un traslado puede ser técnicamente posible pero comercialmente poco atractivo una vez que se consideran la movilización y la producción perdida.
Por ello, yo exigiría que las decisiones sobre recursos consideren los compromisos existentes, la preparación, las fechas requeridas, el esfuerzo de traslado y las consecuencias para el proyecto que libera el recurso.
La funcionalidad de gestión de maquinaria publicada de ProjectVIEW abarca la asignación, la disponibilidad, la utilización y los procesos relacionados con el mantenimiento de la maquinaria. Estos son insumos relevantes para un modelo coordinado de recursos.
Las condiciones de trabajo de los EAU forman parte del plan
La Política de Prevención del Estrés Térmico Laboral 2026 de los EAU prohíbe el trabajo bajo la luz solar directa y en áreas abiertas entre las 12:30 y las 15:00 horas, del 15 de junio al 15 de septiembre de 2026, con sujeción a excepciones específicas y requisitos de protección.
Para la planificación de proyectos, la implicación es práctica: los calendarios, los supuestos de turnos y los pronósticos de recursos deben reflejar las condiciones de trabajo aplicables. Un plan de recursos de cartera basado en supuestos de disponibilidad inadecuados seguirá siendo poco confiable, por muy sofisticado que parezca su tablero.
La nómina y la productividad del proyecto responden a preguntas distintas
La guía del Sistema de Protección Salarial del MoHRE aborda el pago de salarios a través de instituciones financieras autorizadas.
Para el control de proyectos, yo también exigiría que el tiempo de trabajo aprobado se asigne al proyecto y a la actividad correspondientes, y que luego se evalúe frente a la producción física.
Pagar correctamente a un trabajador y comprender el costo del trabajo realizado son responsabilidades conectadas, pero no constituyen el mismo control.
6. Compare el costo final pronosticado, no solo el gasto a la fecha
Un proyecto puede tener un presupuesto restante considerable y, aun así, encaminarse hacia un sobrecosto.
La información que falta es aquello con lo que el contratista ya se ha comprometido y lo que se espera que cueste el trabajo restante.
La relación estándar de la Estimación al Término (EAC) es:
Costo final pronosticado = costo real a la fecha + costo estimado para completar el trabajo restante.
Un proyecto ilustrativo de AED 100 millones
Suponga que un proyecto tiene un presupuesto de costos aprobado de AED 100 millones.
En la fecha de reporte, su costo real incurrido, incluidas las provisiones correspondientes, es de AED 35 millones.
El costo pronosticado del trabajo comprometido restante es de AED 40 millones, excluido todo lo ya incluido en los costos reales. El trabajo restante no comprometido se estima en AED 30 millones.
Por lo tanto, el costo final pronosticado es:
AED 35 millones + AED 40 millones + AED 30 millones = AED 105 millones.
El proyecto solo ha incurrido en AED 35 millones, pero su pronóstico ya indica un sobrecosto de AED 5 millones.
Este es un ejemplo hipotético, no un resultado de un cliente de ProjectVIEW. Supone un alcance, unas reglas de valoración y una fecha de reporte común coherentes.
La conciliación es fundamental. No sume el valor original de la orden de compra a los costos reales cuando una parte de esa orden ya se ha incurrido. Eso contabilizaría dos veces la misma exposición.
En toda la cartera, yo revisaría los cambios en los pronósticos junto con sus causas: revisiones de cantidades, productividad, tarifas de compra, gastos generales de obra adicionales o cambios de alcance aprobados.
El presupuesto restante no es prueba de que el trabajo restante pueda ejecutarse dentro de él.
7. Mantenga separados el avance físico, la certificación y el efectivo
Un contratista necesita información conectada, pero no definiciones intercambiables.
Para fines de gestión, recomiendo mantener distinciones claras entre el trabajo registrado como terminado, el trabajo aceptado según el proceso aplicable, el trabajo certificado para pago, las facturas emitidas y el efectivo cobrado.
Del mismo modo, el sistema debe distinguir un cambio identificado de una variación aprobada.
De lo contrario, un informe de avance optimista puede confundirse con una posición de efectivo segura, o una recuperación potencial puede tratarse como un derecho comercial acordado.
El modelo operativo debe conectar las cantidades pertinentes, los documentos de respaldo, las condiciones contractuales, el estado de revisión y las transacciones financieras, preservando esas distinciones.
El análisis de DANAOS sobre el control de costos más allá del BoQ contractual explica por qué la estructura comercial puede ser demasiado agregada para controlar los recursos consumidos en la ejecución.
Mi recomendación es mantener la línea base original, las revisiones aprobadas y el pronóstico actual como vistas identificables.
Registre la exposición potencial por cambios sin reescribir silenciosamente el presupuesto aprobado ni suponer que se recuperará cada monto reclamado.
8. Ofrezca a la PMO una vista de cartera basada en excepciones
La Oficina de Gestión de Proyectos (PMO) no debería tener que inspeccionar cada transacción para identificar dónde se requiere intervenir.
Yo organizaría su revisión de cartera en torno a un pequeño conjunto de preguntas de decisión.
- Exposición de costos: ¿Qué proyectos tienen pronósticos que se deterioran y qué cambió desde la fecha de reporte anterior?
- Exposición de entrega: ¿Qué materiales, aprobaciones o recursos requeridos amenazan las próximas actividades?
- Conflictos de recursos: ¿Dónde se han prometido las mismas cuadrillas o equipos a requerimientos superpuestos?
- Exposición comercial y de efectivo: ¿Qué certificaciones, cobros, saldos de retenciones o pagos a proveedores requieren atención?
- Confiabilidad de los datos: ¿Qué proyectos tienen envíos de obra atrasados, mapeos sin resolver o transacciones sin conciliar?
Cada excepción debe conducir a un responsable, a evidencia de respaldo y a una acción requerida, no simplemente a un indicador de color.
En una demostración de ERP, pida al proveedor que pase de la vista de cartera al proyecto, al paquete de trabajo y a la transacción subyacente.
La descripción del rol de gestión de proyectos y control de costos de DANAOS ofrece un punto de partida relevante para examinar la información disponible para los gerentes de proyecto.
Un informe consolidado solo es útil cuando la dirección puede explicar qué hay detrás de él.
9. Incorpore la preparación para la facturación electrónica de los EAU al modelo operativo
La facturación electrónica es una razón práctica para examinar cómo se conectan las transacciones del proyecto con los procesos financieros de la entidad contratante.
Según la modificación del calendario de facturación electrónica anunciada el 10 de mayo de 2026 por el Ministerio de Finanzas, el plazo para designar a un Proveedor de Servicios Acreditado para el grupo especificado de grandes empresas se amplió hasta el 30 de octubre de 2026, mientras que la implementación obligatoria se mantuvo para el 1 de enero de 2027. El anuncio se refiere a las empresas incluidas en el ámbito de aplicación con ingresos anuales superiores a AED 50 millones.
La guía de facturación electrónica de los EAU del Ministerio también establece una distinción importante: una factura electrónica son datos de factura electrónicos estructurados. Un PDF, un documento escaneado o un correo electrónico no constituyen, por sí solos, una factura electrónica.
Para un contratista multiproyecto, yo probaría el proceso desde la transacción subyacente hasta la creación de la factura, el intercambio con el proveedor de servicios, la gestión de estados y la conciliación.
La evaluación debe preservar las referencias del proyecto y la información correcta de la entidad, gestionando de forma coherente las excepciones y las notas de crédito.
No suponga que un producto etiquetado como “ERP para los EAU” cuenta con una solución integral validada para cada estructura empresarial. Confirme la aplicabilidad, la configuración y la preparación para la integración con los equipos responsables de finanzas e implementación.
Las referencias normativas reflejan la información oficial revisada en septiembre de 2026.
10. Cómo ProjectVIEW ERP respalda el modelo operativo
El enfoque publicado de ProjectVIEW ERP conecta la información de alcance, ejecución y costos del proyecto mediante su arquitectura BoQ ↔ WBS ↔ Cost Codes.
Su módulo de Control de Costos documenta las conexiones entre presupuestos, avance del proyecto, asignación de recursos y herramientas de programación, incluidas Oracle Primavera P6 y Microsoft Project.
Su módulo de Abastecimiento y Compras aborda el abastecimiento, las cotizaciones, las compras y los requerimientos relacionados del proyecto.
Junto con sus capacidades multiempresa, estas funciones respaldan el modelo operativo previsto por DANAOS: transacciones específicas de cada proyecto que alimentan un marco común de coordinación y gestión.
Sin embargo, una sola plataforma operativa no requiere necesariamente reemplazar todas las aplicaciones especializadas.
El enfoque de integración de ERP con Oracle y SAP publicado por DANAOS describe ProjectVIEW funcionando de forma independiente o junto con un ERP corporativo. El alcance y la titularidad de la integración aún deben diseñarse para cada cliente.
La evaluación debe establecer qué sistema es titular de cada registro, cómo se intercambian las actualizaciones y cómo se resuelven las transacciones fallidas.
La “visibilidad en tiempo real” también debe evaluarse frente a la captura, la aprobación y la sincronización reales de los datos, y no tratarse como un sustituto de ellas.
11. Pruebe tres proyectos conectados antes de comprometerse con un despliegue
Mi escenario de aceptación recomendado utiliza tres proyectos representativos con distintas condiciones de ejecución.
Comience con los presupuestos y cronogramas de los proyectos. Introduzca un requerimiento de material compartido, solicitudes de equipos en competencia y un subcontratista que trabaje en más de un proyecto.
Luego, pruebe si la solución propuesta puede:
- Consolidar las compras conservando las asignaciones a los proyectos y las fechas de entrega.
- Trasladar recursos sin perder la autorización, la valoración ni la responsabilidad.
- Actualizar los costos reales y los pronósticos sin contabilizar dos veces los compromisos.
- Preservar permisos separados por proyecto y por entidad.
- Explicar una excepción de la cartera a través de sus transacciones subyacentes.
A continuación, introduzca una entrega retrasada, una cantidad revisada y un cambio no aprobado.
El propósito no es demostrar que el software puede mostrar los nombres de varios proyectos.
Es determinar si la organización puede coordinar esos proyectos manteniendo el control sobre cada uno de ellos.
Para conocer el alcance de producto correspondiente, consulte ERP de construcción para contratistas generales
.
Reflexión final
La cartera de un contratista en los EAU no debería convertirse en un conjunto de presupuestos desconectados que compiten por los mismos recursos.
Tampoco la centralización debería borrar las diferencias comerciales y operativas entre los proyectos.
La visión de DANAOS Projects es que un control multiproyecto eficaz requiere una lógica de negocio compartida con responsabilidad a nivel de proyecto.
La dirección debe poder ver qué se necesita, qué está comprometido, qué se ha consumido, qué se ha entregado y qué sigue expuesto.
La pregunta no es simplemente:
“¿Puede nuestro ERP gestionar múltiples proyectos?”
Es:
“¿Podemos tomar una decisión sobre un proyecto comprendiendo —y controlando— sus consecuencias para el resto de la empresa?”
Esa es la prueba de una sola plataforma operativa.
