La desconexión BoQ-WBS: cómo estructurar los códigos de costo del ERP para eliminar los sobrecostos en megaproyectos

El control de costos de los megaproyectos falla cuando el alcance comercial, la ejecución del proyecto y el costo real se describen en lenguajes diferentes.

 

• El estimador piensa en Presupuesto de Cantidades (BoQ).
• El planificador piensa en Estructura de Desglose del Trabajo (WBS).
• Compras piensa en materiales, órdenes de compra y subcontratos.
• La obra piensa en cantidades instaladas, horas de mano de obra, utilización de equipos y producción diaria.
• Finanzas piensa en códigos de costo, cuentas, facturas, devengos y períodos contables.

 

Cada una de estas visiones puede ser correcta por separado.

 

Pero si no pueden conciliarse de inmediato, la dirección no tiene un control de costos del proyecto en tiempo real. Tiene múltiples representaciones del mismo proyecto que tarde o temprano deberán conciliarse.

 

Esa distinción es fundamental.

 

El alza de precios del mercado, los cambios de alcance, el desarrollo del diseño, la pérdida de productividad, las interrupciones logísticas, las disputas contractuales y las condiciones imprevistas pueden causar sobrecostos legítimos en un proyecto.

 

Pero los datos de proyecto desconectados generan otro problema:

 

 

El trabajo de Baker Tilly en proyectos de capital identifica informes de costos sin conciliar, registros financieros y operativos incoherentes, controles presupuestarios débiles, visibilidad tardía y procesos deficientes de control de proyectos entre los riesgos recurrentes de la construcción. Su metodología de asesoría en proyectos de capital hace hincapié en el seguimiento integrado del avance, los gastos, el cronograma y la calidad del trabajo. Baker Tilly — Asesoría en proyectos de capital Baker Tilly — Caso de estudio sobre transparencia de costos de construcción

 

La respuesta estructural no es otro tablero de control.

 

Es una arquitectura integrada de control de costos.

 

En ProjectVIEW ERP, esa arquitectura comienza con:

 

 

ProjectVIEW OS — Arquitectura de BoQ, WBS y códigos de costo

 

---

 

¿Qué es la desconexión BoQ–WBS?

 

La desconexión BoQ–WBS se produce cuando el alcance comercial utilizado para estimar y cotizar un proyecto no puede conciliarse sistemáticamente con la estructura de trabajo utilizada para planificarlo y ejecutarlo, ni con la estructura de codificación utilizada para registrar su costo real.

 

Considere un gran paquete de infraestructura.

 

La licitación puede incluir una partida del BoQ de 150.000 m³ de excavación.

 

El cronograma puede dividir ese alcance entre zonas, estructuras, frentes de trabajo y múltiples actividades de la WBS.

 

Finanzas puede recibir costos bajo mano de obra de excavación, equipos alquilados, combustible, subcontratistas, transporte y disposición final.

 

Por lo tanto, el proyecto puede contener la misma realidad económica en tres estructuras diferentes:

 

• BoQ: ¿Qué cotizamos y nos comprometimos a entregar?
• WBS: ¿Qué trabajo debe realizarse, dónde y cuándo?
• Códigos de costo: ¿Qué recursos y costos se están consumiendo para entregarlo?

 

Si las relaciones entre estas dimensiones son débiles, el equipo del proyecto puede saber cuánto ha gastado sin saber con precisión qué ha producido ese gasto.

 

O puede saber que se ha logrado un avance físico sin conocer el costo completo de obtener ese avance.

 

Ese es exactamente el problema que la Gestión del Valor Ganado (EVM) pretende poner de manifiesto.

 

¿Por qué la desconexión rompe la Gestión del Valor Ganado?

 

La Gestión del Valor Ganado PMI — La Gestión del Valor Ganado explicada integra tres mediciones fundamentales:

 

• Valor Planificado (PV): el valor presupuestado del trabajo planificado hasta la fecha de corte.
• Valor Ganado (EV): el valor presupuestado del trabajo efectivamente completado.
• Costo Real (AC): el costo efectivamente incurrido para realizar ese trabajo.

 

A partir de esas tres medidas:

 

• Variación del costo: CV = EV − AC
• Variación del cronograma: SV = EV − PV
• Índice de desempeño del costo: CPI = EV / AC
• Índice de desempeño del cronograma: SPI = EV / PV

 

La guía actual del PMI sobre EVM subraya que la aritmética es sencilla; la calidad de la información subyacente de alcance, cronograma, costo y avance es la que determina si el resultado tiene sentido.

 

La Oficina de Rendición de Cuentas del Gobierno de EE. UU. (GAO) va más allá.

 

Su Guía de Estimación y Evaluación de Costos establece que debe existir una única WBS del proyecto, alineada con la WBS utilizada por la estimación de costos y el cronograma, de modo que los costos reales puedan retroalimentar a ambos. También identifica la cuenta de control como el punto en el que se recopilan los costos reales y se miden las variaciones respecto de la línea base. Guía de Estimación y Evaluación de Costos de la GAO — Gestión del Valor Ganado

 

Esto conduce a una conclusión crucial:

 

 

El verdadero problema es tanto de tiempos como de codificación

 

Hay otra razón por la que los sistemas fragmentados producen información de control de proyectos engañosa.

 

El Valor Ganado y el Costo Real deben representar el mismo trabajo durante el mismo período de medición.

 

La guía EVMS del Departamento de Energía de EE. UU. aborda explícitamente este problema. Cuando se han recibido materiales pero aún no han llegado las facturas del proveedor, pueden ser necesarios costos reales estimados para que el costo se reconozca en el mismo período en que se registra el valor ganado; de lo contrario, el proyecto puede generar variaciones falsas. Departamento de Energía de EE. UU. — Guía EVMS

 

La explicación actual de PLANTA sobre la Gestión del Valor Ganado plantea lo mismo: los retrasos en el registro de los costos reales pueden generar indicadores de desempeño engañosos, porque el Valor Ganado deja de corresponderse con los costos efectivamente incurridos para ese trabajo. PLANTA — Gestión del Valor Ganado y pronóstico de costos

 

Este es el desfase fatal de los datos.

 

Un proyecto puede parecer sano porque se ha registrado el trabajo, pero no su costo completo.

 

• Luego llegan las facturas.
• Se registran los devengos.
• Se aprueban los certificados de los subcontratistas.
• Se asignan los cargos de equipos.
• Se cierra la nómina.
• El margen aparente desaparece.
• El sobrecosto no ocurrió de repente al cierre del mes.

 

 

¿Cómo deben estructurarse el BoQ, la WBS y los códigos de costo del ERP?

 

A veces el objetivo se describe como una relación 1:1:1 entre el BoQ, la WBS y los códigos de costo.

 

Como orientación es útil, pero técnicamente resulta demasiado simplista para los grandes proyectos.

 

Un proyecto complejo puede contener legítimamente una partida del BoQ ejecutada mediante varias actividades del cronograma. Varias partidas comerciales del BoQ también pueden compartir una misma clasificación interna de recursos o de costos.

 

Por lo tanto, el objetivo no debería ser forzar una cardinalidad uno a uno.

 

El objetivo debería ser:

 

 

La arquitectura publicada de ProjectVIEW admite explícitamente la vinculación de los códigos del BoQ con la WBS y una asociación de muchos a uno entre los códigos del BoQ y los códigos de costo internos, en lugar de pretender que todo proyecto puede reducirse a una estructura artificial uno a uno. Folleto de ProjectVIEW ERP — Conectividad trilateral

 

Una implementación sólida debería establecer un único modelo de codificación gobernado en cinco capas:

 

1. Alcance comercial: cada línea relevante del BoQ identifica la cantidad, la unidad, el valor comercial y el alcance cotizado.
2. Estructura de ejecución: los elementos de la WBS y los paquetes de trabajo definen cómo y cuándo se ejecutará el alcance.
3. Clasificación de costos: los códigos de costo internos o la Estructura de Desglose de Costos clasifican de manera coherente la mano de obra, los materiales, los equipos, los subcontratistas y otros costos directos.
4. Cuentas de control: los puntos de control de la dirección integran alcance, cronograma, presupuesto, responsabilidad organizativa y costos reales.
5. Mapeo de transacciones: las compras, las salidas de materiales, la mano de obra, la maquinaria, los subcontratistas, la caja chica, el avance y demás transacciones reales heredan la codificación de proyecto correspondiente, en lugar de conciliarse manualmente después.

 

El resultado no es simplemente un mejor reporte.

 

Se crea un modelo económico del proyecto legible por máquina.

 

¿Por qué son tan importantes las cuentas de control?

 

Una cuenta de control es más que otro campo de centro de costos.

 

El Departamento de Defensa de EE. UU. define la cuenta de control como el punto de gestión en el que se acumulan los presupuestos y los costos reales y se comparan con el valor ganado a efectos de control de gestión. DoD de EE. UU. — Definiciones de la Gestión del Valor Ganado

 

De forma similar, el PMI la describe como el punto en el que se reúnen alcance, cronograma, presupuesto y costo real para medir el desempeño. PMI — Integración de alcance, cronograma y costo mediante cuentas de control

 

Esa es la arquitectura que necesita el control de costos de los megaproyectos.

 

El BoQ por sí solo no basta.

 

La WBS por sí sola no basta.

 

El libro mayor por sí solo no basta.

 

La dirección necesita una estructura de control en la que la misma unidad de trabajo pueda responder simultáneamente cuatro preguntas:

 

• ¿Qué nos comprometimos a entregar?
• ¿Cuándo debíamos entregarlo?
• ¿Cuánto valor hemos ganado realmente?
• ¿Cuánto costó realmente lograr ese avance?

 

Sin ese punto de control común, la variación del costo se convierte en un ejercicio de conciliación en lugar de una señal operativa.

 

De la estimación de la licitación al presupuesto de ejecución

 

Una fuente importante de fallas en el control de costos se produce incluso antes de que comience la construcción.

 

• La licitación se gana con una estructura de estimación.
• Luego el equipo del proyecto crea otro presupuesto.
• El departamento de planificación desarrolla otra WBS.
• Finanzas establece otra estructura contable.
• Compras empieza a codificar las órdenes de compra según otra taxonomía.
• En pocas semanas, la lógica comercial original que justificó la oferta ganadora empieza a desaparecer.

 

Esto destruye una relación de enorme valor:

 

 

La arquitectura de Estimación Presupuestaria y Licitación de ProjectVIEW admite la importación del BoQ, las estructuras de cantidades, el modelado de riesgos y gastos generales, la sincronización BoQ–WBS y la creación del presupuesto de costos dentro del mismo entorno empresarial. DANAOS Master SaaS Framework — Estimación Presupuestaria y Licitación en ProjectVIEW

 

Su flujo de procesos maestro conecta luego el BoQ, la WBS y el presupuesto de costos con las compras, los materiales, los subcontratistas, la mano de obra, la maquinaria, el avance del proyecto, el costo real, los contratos con clientes y la contabilidad. Flujos de procesos maestros de ProjectVIEW ERP

 

Esa continuidad es importante porque la estimación ganadora no debería convertirse en un documento arqueológico después de la adjudicación del contrato.

 

Debería convertirse en la línea base económica frente a la cual se pone a prueba continuamente la ejecución.

 

¿Qué significa realmente el control de costos en tiempo real?

 

El “control de costos en tiempo real” se malinterpreta con frecuencia.

 

No significa recalcular cada segundo un pronóstico financiero sin control.

 

Los informes formales de Valor Ganado siguen requiriendo líneas base controladas, fechas de corte, cambios aprobados y períodos contables disciplinados.

 

El control de costos en tiempo real significa reducir la latencia entre un evento operativo y la capacidad de la dirección para ver su impacto económico.

 

• Cuando un ingeniero de obra registra un avance, el sistema debería saber qué trabajo se realizó.
• Cuando se entregan materiales, el sistema debería saber qué paquete de trabajo los consumió.
• Cuando se registra mano de obra, el sistema debería saber qué actividad del proyecto utilizó esas horas.
• Cuando opera la maquinaria, su costo debería poder atribuirse al trabajo correspondiente.
• Cuando se aprueba un certificado de subcontratista, el alcance y el presupuesto del proyecto asociados ya deberían conocerse.

 

Esa es la filosofía detrás del modelo de campo a oficina de ProjectVIEW ERP. Su arquitectura de construcción publicada conecta el avance diario con el consumo de materiales, la productividad de la mano de obra y la utilización de la maquinaria, al tiempo que asocia los procesos con el BoQ, la WBS y los códigos de costo. ProjectVIEW ERP — Arquitectura de control de costos de construcción y de obra

 

La cuestión no es tener más datos.

 

 

Del reporte pasivo de costos al pronóstico activo

 

El reporte tradicional de costos pregunta:

 

• ¿Cuánto gastamos el mes pasado?

 

El control de proyectos debería preguntar:

 

• Con lo que sabemos hoy, ¿cuánto costará este proyecto cuando termine?

 

Ese es el propósito de la Estimación a la Conclusión (EAC).

 

El PMI identifica varios enfoques de pronóstico según la hipótesis que se adopte sobre el desempeño futuro. Si se espera que la eficiencia actual de costos continúe:

 

EAC = BAC / CPI

 

Si la variación histórica se considera excepcional y se espera que el trabajo restante se desempeñe conforme al presupuesto original:

 

EAC = AC + (BAC − EV)

 

Otros enfoques utilizan una nueva Estimación hasta la Conclusión ascendente o incorporan tanto el desempeño del costo como el del cronograma. PMI — Pronóstico con EVM y Estimación a la Conclusión

 

De forma similar, PLANTA describe EAC, ETC, VAC y TCPI como medidas prospectivas de control de proyectos que convierten el desempeño pasado y actual en una visión del costo final esperado. PLANTA — EAC y métricas de pronóstico EVM

 

Lo importante no es qué fórmula gana.

 

Es si la información que alimenta la fórmula es confiable.

 

Si el avance se informa contra la Actividad A de la WBS mientras su costo real queda oculto dentro de un código de costo contable que también contiene las Actividades B, C y D, la precisión de la fórmula de pronóstico se vuelve irrelevante.

 

El cálculo puede ser matemáticamente exacto y operativamente erróneo.

 

Del historial contable a la previsión del proyecto

 

La contabilidad financiera tradicional es esencial.

 

Pero la contabilidad responde a otra pregunta.

 

Registra y gobierna lo que la empresa ha incurrido financieramente.

 

El control de costos del proyecto debe comprender además qué trabajo generó ese costo y qué implica el desempeño actual para el futuro.

 

Por eso un libro mayor, un programador de cronogramas y un tablero de BI no pueden convertirse automáticamente en un entorno integrado de control de proyectos simplemente intercambiando archivos.

 

Una arquitectura centrada en el proyecto debe preservar la relación semántica entre:

 

alcance → cantidad → cronograma → recurso → compromiso → costo real → avance → pronóstico

 

ProjectVIEW describe esto como su núcleo de proyecto BoQ ↔ WBS ↔ Códigos de costo. ProjectVIEW OS — Lógica de negocio centrada en el proyecto

 

El valor de ese núcleo aumenta a medida que las empresas incorporan análisis predictivo e IA.

 

¿Qué cambia cuando la IA entra en el control de costos del proyecto?

 

La IA no elimina la necesidad de un control de proyectos disciplinado.

 

La aumenta.

 

Un modelo de lenguaje de gran tamaño puede resumir miles de registros.

 

Un agente de IA puede analizar cotizaciones.

 

Los modelos de aprendizaje automático pueden detectar patrones de costos inusuales.

 

Los motores de pronóstico pueden identificar tendencias emergentes.

 

Pero la IA no puede compensar datos de proyecto fundamentalmente ambiguos.

 

Si la empresa no sabe qué costos reales corresponden a qué alcance, actividad y período de reporte, la IA hereda la misma incertidumbre.

 

Por eso DANAOS sostiene que el ERP debe ir antes que la IA. DANAOS — Por qué el ERP va antes que la IA

 

La visión publicada de ProjectVIEW OS construye ProjectVIEW AI sobre la capa estructurada del ERP, y la relación BoQ–WBS–Código de costo aporta un contexto de proyecto legible por máquina. ProjectVIEW OS — Arquitectura de ERP e IA

 

Con esa base, la IA puede respaldar progresivamente preguntas de mayor valor.

 

En lugar de:

 

• “¿Cuánto hemos gastado?”

 

la IA puede investigar:

 

• “¿Por qué se está deteriorando el desempeño de costos del hormigón en la Zona 3?”

 

En lugar de:

 

• “¿Cuál es nuestro CPI actual?”

 

puede ayudar a preguntar:

• “¿Qué paquetes de trabajo están provocando el deterioro del CPI y qué implica la productividad actual para la EAC?”

 

En lugar de:

 

• “¿Qué órdenes de compra superan el presupuesto?”

 

puede ayudar a investigar:

 

• “¿Qué compromisos de compra tienen más probabilidades de generar un sobrecosto presupuestario futuro si se consideran las cantidades, los precios y el alcance restante actuales?”

 

Esta es la transición de la recuperación de datos al razonamiento operativo.

 

La IA no reemplaza la Gestión del Valor Ganado

 

Esta distinción es importante.

 

La IA no debería inventar el Valor Ganado, el Costo Real, la variación del costo ni la variación del cronograma.

 

Esos valores deben originarse en datos de proyecto gobernados y en reglas de negocio definidas.

 

El papel de la IA es más valioso en otros ámbitos:

 

detectar anomalías → investigar causas → identificar relaciones → pronosticar escenarios → explicar la exposición → recomendar acciones

 

Por lo tanto, la estrategia de ProjectVIEW puede entenderse en dos capas:

 

ProjectVIEW ERP proporciona la capa determinista de Procesos y Datos.

 

ProjectVIEW AI proporciona la capa de Inteligencia y Autonomía.

 

ProjectVIEW OS — Ejecución digital e inteligencia autónoma

 

La capa determinista le indica a la IA qué es verdadero según el sistema de registro de la empresa.

 

La capa de razonamiento ayuda a la dirección a decidir qué significa esa verdad.

 

Por qué un programador de cronogramas por sí solo no puede resolver el problema

 

Un sistema de programación avanzado como Primavera P6 puede proporcionar la WBS, las actividades, la lógica, los hitos y la dimensión temporal que exige la planificación avanzada de proyectos.

 

Eso es indispensable.

 

Pero la información del cronograma por sí sola no contiene automáticamente la realidad comercial y transaccional completa de la ejecución del proyecto.

 

Por eso ProjectVIEW se integra con Primavera en lugar de intentar que el programador del ERP reemplace al software de planificación especializado.

 

La arquitectura de ProjectVIEW ERP conecta las estructuras WBS de Primavera con los códigos del BoQ, los presupuestos y los procesos reales del proyecto, de modo que el avance del cronograma pueda evaluarse frente a la estructura comercial y de costos. Folleto de ProjectVIEW ERP — Integración de Primavera, BoQ y costos

 

La distinción arquitectónica es sencilla:

 

La planificación le dice a la dirección cuándo debe realizarse el trabajo.

 

 

Ambos adquieren mucho más valor cuando hablan el mismo lenguaje de codificación.

 

Por qué un ERP generalista por sí solo tampoco puede resolverlo

 

Los sistemas ERP corporativos cumplen funciones esenciales, como contabilidad, compras, tesorería, nómina, gestión de activos y consolidación financiera.

 

Pero el control de costos de los proyectos de capital requiere otra dimensión:

 

la estructura económica del propio proyecto.

 

El propio análisis de DANAOS sobre las arquitecturas de ERP generalistas sostiene que las listas de materiales (BOM), los códigos de costo, los centros de costos y los BoQ no son construcciones intercambiables, y que una planificación basada en la WBS sin un alcance comercial basado en cantidades puede dejar vacíos importantes en el control del proyecto. DANAOS — Análisis estructural de los ERP generalistas en proyectos de capital

 

La respuesta no es eliminar automáticamente el ERP corporativo.

 

ProjectVIEW admite integraciones con SAP, Oracle, Primavera y otros entornos empresariales. ProjectVIEW ERP — Arquitectura de integración

 

El objetivo arquitectónico es más pragmático:

 

 

La dura verdad: el software no corrige un control de proyectos deficiente

 

Una empresa puede adquirir uno de los sistemas ERP más avanzados del mundo y seguir produciendo pronósticos de costos poco fiables.

 

La tecnología no puede compensar:

 

la titularidad ambigua del alcance; la codificación incoherente; los cambios de línea base no aprobados; el reporte tardío del avance; los devengos faltantes; las cantidades inexactas; las transferencias de costos sin control; la escasa disciplina en compras; o los equipos de proyecto que eluden los flujos de trabajo definidos.

 

La metodología de asesoría en construcción de Baker Tilly hace hincapié en las estructuras de control de proyectos, las políticas, los procedimientos, el reporte de costos, el seguimiento del avance y la rendición de cuentas, no simplemente en la implantación de tecnología. Baker Tilly — Auditoría de construcción y control de proyectos

 

El PMI plantea esencialmente lo mismo desde la perspectiva del EVM: una plataforma puede calcular con exactitud las métricas de valor ganado y aun así dar a la dirección información engañosa si la línea base subyacente es débil. PMI — Gestión del Valor Ganado: cómo leer las cifras

 

DANAOS expresa el principio de forma similar en su propia estrategia de preparación para la IA:

 

primero estandarizar el proceso, después estructurar los datos y, por último, automatizar y aplicar la IA.

 

DANAOS — Caminar antes de correr: por qué el ERP va antes que la IA

 

La arquitectura del control continuo de costos

 

El modelo tradicional de control de proyectos suele verse así:

 

Ejecutar → Esperar → Recopilar → Conciliar → Informar → Explicar

 

Para cuando la alta dirección recibe la explicación, las opciones correctivas pueden ser ya limitadas.

 

El mejor modelo es:

 

 

Los flujos maestros de ProjectVIEW conectan el presupuesto de costos con las transacciones de obra, la mano de obra, la maquinaria, los materiales, las compras, los subcontratistas, el avance, los ingresos y la contabilidad. ProjectVIEW ERP — Flujo de procesos maestro integrado

 

Esto sienta las bases de lo que DANAOS denomina una verificación de la realidad continua del proyecto.

 

Cada transacción operativa puede evaluarse frente a dos dimensiones fundamentales:

 

• TIEMPO, a través de la WBS

 

y

 

• COSTO, a través de la estructura de BoQ, presupuesto y códigos de costo.

 

El objetivo no es descubrir que el proyecto superó el presupuesto.

 

 

¿Qué es el “Quantum Cost Control”?

 

DANAOS utiliza el término Quantum Cost Control para describir el control de costos a nivel granular de transacciones y procesos del proyecto, en lugar de hacerlo exclusivamente mediante informes financieros agregados periódicos.

 

En ProjectVIEW ERP, el análisis real frente a presupuesto, el avance del proyecto, las compras, los subcontratistas, la mano de obra, la maquinaria y las transacciones de obra existen dentro del mismo modelo de información centrado en el proyecto. ProjectVIEW ERP — Control de costos y desempeño del proyecto

 

El concepto es sencillo:

 

Si cada evento económicamente relevante puede asociarse con su contexto de proyecto, la dirección no necesita esperar a que se concilie manualmente información desconectada para comprender el desempeño.

 

Eso no elimina la incertidumbre.

 

Elimina la latencia informativa innecesaria.

 

Y en el control de costos de los megaproyectos, la latencia puede resultar extremadamente costosa.

 

---

 

Preguntas frecuentes sobre BoQ, WBS y códigos de costo del ERP

 

¿Cuál es la diferencia entre un BoQ y una WBS?

 

Un Presupuesto de Cantidades (BoQ) estructura el alcance comercial medible, las cantidades, las unidades y los precios. Una Estructura de Desglose del Trabajo (WBS) descompone el alcance del proyecto en elementos de ejecución gestionables que se utilizan para la planificación, la asignación de responsabilidades y la programación.

 

Describen dimensiones distintas del mismo proyecto y, por lo tanto, deberían estar conectados de forma relacional en lugar de tratarse como sustitutos.

 

¿Qué es un código de costo del ERP?

 

Un código de costo del ERP es una clasificación estructurada que se utiliza para asignar el gasto del proyecto a una categoría u objeto de costo definido.

 

En un ERP orientado a proyectos, los códigos de costo adquieren mucha más potencia cuando se conectan con el alcance del BoQ y las estructuras de ejecución de la WBS, porque la dirección puede entonces comprender tanto qué se gastó como qué trabajo respaldó ese gasto.

 

ProjectVIEW ERP — Arquitectura de BoQ, WBS y códigos de costo internos

 

¿Por qué la desconexión BoQ–WBS genera un control de costos deficiente?

 

Cuando el alcance del BoQ y la ejecución de la WBS no pueden conciliarse, la cantidad, el avance del cronograma y el costo real describen el proyecto en niveles diferentes.

 

Esto dificulta comparar el Valor Planificado, el Valor Ganado y el Costo Real para el mismo alcance y período de reporte, y aumenta la dependencia de la conciliación manual.

 

¿El mapeo entre BoQ, WBS y códigos de costo tiene que ser 1:1:1?

 

No.

 

Un megaproyecto suele ser demasiado complejo para una relación literal uno a uno.

 

El requisito es una trazabilidad completa y gobernada.

 

ProjectVIEW, por ejemplo, admite la asociación BoQ–WBS y el mapeo de muchos a uno entre los códigos del BoQ y los códigos de costo internos. Folleto de ProjectVIEW ERP — Conectividad trilateral

 

¿Qué es una cuenta de control en la Gestión del Valor Ganado?

 

Una cuenta de control es un punto de control de gestión en el que se integran el alcance, el presupuesto, el cronograma, el costo real y la responsabilidad organizativa del proyecto para medir el desempeño.

 

Tanto el PMI como la guía EVMS del gobierno de EE. UU. consideran las cuentas de control fundamentales para una Gestión del Valor Ganado fiable. PMI — Cuentas de control en EVM DoD de EE. UU. — Definición de cuenta de control

 

¿Qué es la variación del costo en EVM?

 

Variación del costo (CV) = Valor Ganado (EV) − Costo Real (AC).

 

Una CV negativa indica que el costo incurrido supera el valor presupuestado del trabajo efectivamente completado.

 

PMI — Métricas y fórmulas del Valor Ganado

 

¿Qué es la variación del cronograma en EVM?

 

Variación del cronograma (SV) = Valor Ganado (EV) − Valor Planificado (PV).

 

Una SV negativa significa que el valor presupuestado del trabajo completado es inferior al valor planificado para completarse hasta la fecha de corte.

 

PMI — Métricas y fórmulas del Valor Ganado

¿Por qué el Costo Real y el Valor Ganado deben registrarse en el mismo período?

 

Porque la CV compara el valor ganado por el trabajo realizado con el costo incurrido para realizar ese mismo trabajo.

 

Si el costo se registra después que el avance, el proyecto puede mostrar una posición de costos artificialmente favorable. La guía EVMS de EE. UU. aborda específicamente la necesidad de utilizar costos reales estimados cuando corresponda para evitar variaciones falsas. DOE de EE. UU. — Alineación de costos reales y valor ganado

 

¿Qué es la Estimación a la Conclusión?

 

La Estimación a la Conclusión (EAC) pronostica el costo total esperado del proyecto al finalizar.

 

Una fórmula habitual es:

 

EAC = BAC / CPI

 

cuando se supone que la eficiencia actual de costos continuará.

 

Los distintos métodos de EAC deben seleccionarse según la hipótesis de pronóstico, en lugar de aplicarse mecánicamente. PMI — Pronóstico de la Estimación a la Conclusión

 

¿Cómo mejora la IA el pronóstico de costos del proyecto?

 

La IA puede ayudar a detectar patrones de costos inusuales, identificar los factores que deterioran el desempeño, analizar resultados históricos y evaluar escenarios de pronóstico.

 

Sin embargo, el pronóstico con IA solo es tan fiable como el contexto de proyecto que se le proporciona. Las relaciones estructuradas entre alcance, cronograma, cantidades, costo y ejecución real ofrecen a la IA una base más sólida que las hojas de cálculo o las transacciones contables desconectadas.

 

ProjectVIEW OS — IA y datos estructurados del proyecto

 

¿Puede ProjectVIEW ERP integrarse con Primavera P6?

 

Sí.

 

ProjectVIEW admite la integración con Primavera y conecta las estructuras de planificación de la WBS con la información del BoQ, del presupuesto y de la ejecución del proyecto.

 

Folleto de ProjectVIEW ERP — Integración con Primavera

 

¿ProjectVIEW reemplaza un ERP corporativo existente?

 

No necesariamente.

 

ProjectVIEW puede funcionar como la capa de construcción y control de costos centrada en el proyecto, integrándose con los entornos empresariales corporativos ya establecidos, incluidos SAP y los sistemas relacionados con Oracle.

 

ProjectVIEW OS — Integraciones empresariales

 

¿Cómo respalda ProjectVIEW ERP el control de costos de construcción en tiempo real?

 

ProjectVIEW conecta BoQ, WBS, códigos de costo, presupuesto, compras, subcontratistas, materiales, mano de obra, maquinaria, avance de obra y contabilidad dentro de un modelo de datos de proyecto integrado.

 

Su arquitectura publicada admite el seguimiento de lo real frente a lo presupuestado y conecta la actividad de campo con la estructura de proyectos de la empresa. Folleto de ProjectVIEW ERP — Control de costos de construcción

 

El principio final

 

El control de costos de los megaproyectos no es principalmente un problema de tableros de control.

 

Tampoco es solo un problema contable.

 

Tampoco es solo un problema de programación.

 

Y no es un problema de IA.

 

Es un problema de arquitectura.

 

El alcance comercial debe conectarse con la ejecución.

 

La ejecución debe conectarse con el cronograma.

 

El cronograma debe conectarse con el presupuesto.

 

Los recursos deben conectarse con el trabajo.

 

El costo real debe conectarse con el alcance que lo generó.

 

El avance y el costo deben medirse en períodos comparables.

 

El pronóstico debe heredar esa misma estructura.

 

Solo entonces el EVM, el análisis predictivo y la IA pueden operar sobre una realidad de proyecto fiable.

 

Por eso la relación:

 

 

es más que una funcionalidad de ProjectVIEW.

 

Es la base de una arquitectura de control de costos centrada en el proyecto.

 

• El BoQ le dice qué vendió.
• La WBS le dice cómo y cuándo pretende construirlo.
• El código de costo le dice qué está consumiendo la empresa para ejecutarlo.