Modelo matemático de un presupuesto de obra

Un presupuesto de obra no es una tabla. Tampoco es un archivo. Mucho menos una colección de importes acomodados por partidas.

Lo que solemos ver primero —clave, concepto, unidad, cantidad, precio unitario, importe— es solo la salida visible de un sistema más profundo. El presupuesto real está en la estructura que produce esos números: insumos, matrices, rendimientos, factores y volúmenes.

Esa diferencia importa porque cambia por completo la forma de revisarlo. Si solo lees renglones, puedes ver cuánto cuesta algo. Si entiendes la estructura, puedes empezar a responder la pregunta importante: por qué cuesta eso.

Esa es justamente la utilidad de presupuestos.red: abrir presupuestos de OPUS y Neodata desde el navegador, sin instalación ni cuenta, con procesamiento local en el dispositivo, para consultar catálogo, matrices de precios unitarios, explosión de insumos y exportar a Excel. El proyecto nació de una necesidad muy concreta: revisar presupuestos en cualquier equipo, sin depender de Windows, licencias o software instalado.

El archivo es solo el contenedor

En obra y en licitación, el problema muchas veces no es que el presupuesto no exista, sino que existe en un formato poco práctico.

Te mandan un respaldo .bak, un conjunto .dbf, un.pu6 o un intercambio .zip. La información está ahí, pero abrirla puede exigir una versión específica del programa, una licencia activa o incluso una máquina con Windows. Las guías del sitio están construidas precisamente sobre ese escenario: revisar un presupuesto recibido para licitación, cotización o concurso sin tener instalado OPUS o Neodata.

Por eso conviene separar dos cosas que en la práctica suelen confundirse:

• el archivo, que transporta la información;
• y el presupuesto, que es la lógica de cálculo contenida en ese archivo.

Confundir ambas cosas lleva a pensar que revisar un presupuesto es abrirlo y leer sus totales. En realidad, abrirlo es apenas el principio.

El primer nivel: los insumos base

Todo presupuesto descansa en recursos base: materiales, mano de obra, equipo, herramienta y equivalentes según el sistema de origen.

Si llamamos $\mathcal{I}$ al conjunto de insumos, cada insumo $i \in \mathcal{I}$ tiene un costo unitario base $C_i$. En ese punto, el cálculo ya no se descompone dentro del presupuesto que estamos evaluando. El insumo es el lugar donde la recursión se detiene.

Eso importa porque el presupuesto no se sostiene primero en el precio unitario del concepto, sino en la consistencia de ese nivel más bajo. Si el catálogo de insumos viene mal capturado, si los costos base son dudosos o si una misma clave se usa con criterios distintos, el resto del presupuesto no corrige el problema. Solo lo propaga.

La jerarquía visible y la estructura real

Todo presupuesto tiene una organización visible: capítulos, partidas, subpartidas, conceptos. Esa jerarquía sirve para ubicar información, presentar el catálogo y agrupar importes.

Pero el costo no se calcula ahí.

El costo se calcula en otra capa: la de las matrices y sus dependencias. Un concepto puede depender de una matriz auxiliar. Esa matriz puede depender de otra. Y una misma auxiliar puede reutilizarse en varios conceptos. Eso significa que la estructura de cálculo no es solo un árbol de agrupadores, sino una red de composición que debe poder recorrerse de manera consistente.

Dicho de forma práctica: una cosa es dónde está un concepto dentro del presupuesto; otra, muy distinta, es de qué está hecho.

La primera estructura sirve para navegar.

La segunda sirve para entender.

Y eso es exactamente lo que vuelve útil un visor que no se limita a mostrar renglones, sino que deja entrar a catálogo, matrices y explosión. El sitio describe precisamente esas vistas como parte central de lo que puede consultarse tanto para OPUS como para Neodata.

Donde de verdad se tuercen los presupuestos: cantidades y rendimientos

La parte delicada no suele estar en la suma final, sino en la interpretación de las matrices.

Hay componentes que entran por cantidad directa: tantas piezas, tantos kilos, tantos metros cúbicos, tantas jornadas. Ahí el requerimiento por unidad es inmediato.

Pero hay otros que entran por rendimiento. Una cuadrilla puede capturarse como 8 m² por jornada en vez de 0.125 jornadas por m². En ese caso, el consumo real por unidad no es el rendimiento mismo, sino su inverso.

Ese detalle, que parece menor, es decisivo. Un rendimiento mal interpretado no altera solo una celda: deforma toda la cadena de cálculo que depende de él.

El costo directo sí es una definición recursiva

Aquí conviene ser precisos.

Esta formulación sí expresa lo que realmente ocurre.

Si $x$ es un insumo base, su costo directo es simplemente su costo base.

Si $x$ es una matriz o un básico (sub-matriz), su costo directo es la suma de los costos directos de sus componentes, ponderados por su requerimiento efectivo $Q(k,x)$.

Y ese requerimiento efectivo puede venir de dos formas:

• como cantidad directa;
• o como inverso de un rendimiento.

La importancia de escribirlo así es que ya no fingimos que todos los insumos son base. La ecuación reconoce explícitamente que una matriz o un básico puede depender de otro, y que el costo solo queda resuelto cuando la expansión llega por fin a las hojas del sistema.

Un ejemplo pequeño: el muro no cuesta lo que dice el renglón

Supongamos un concepto de muro de block asentado con mortero.

En la vista resumida del presupuesto solo verás algo como esto:

Pero debajo puede existir una estructura de composición como esta:

Además de herramienta menor o cargos relacionados, según el criterio del análisis

Y el mortero, a su vez, puede depender de:

• cemento
• arena
• agua
• mano de obra de preparación, si está modelada
• equipo menor, si está separado

Entonces el costo del muro no sale del renglón final. Sale de resolver primero el mortero, luego integrar block, cuadrilla y demás componentes, y solo después calcular el costo directo del concepto.

Eso cambia la forma de revisar. La pregunta deja de ser solamente “¿cuánto cuesta este muro?” y se vuelve “¿qué lo está haciendo costar eso?”.

Del costo directo al precio unitario

Una vez resuelta la composición, todavía falta transformar el costo directo en precio unitario.

Aquí la notación vaga del tipo $\text{PU}=f(\text{CD})$ no ayuda mucho, porque justo borra la diferencia que sí importa. Lo relevante es que no da lo mismo aplicar factores en cascada que aplicarlos sobre una base común.

Si $\text{CD}_c$ es el costo directo del concepto $c$, un esquema acumulativo puede escribirse así:

Donde:

En cambio, un esquema sobre base común puede escribirse así:

Estas dos expresiones no son equivalentes salvo en casos triviales. Y esa diferencia no es académica: explica por qué dos presupuestos con porcentajes parecidos pueden producir precios unitarios distintos.

Eso también explica por qué un Excel resumido suele quedarse corto. Conserva el número final, pero pierde la operación que lo generó.

El volumen no corrige nada, solo escala

Después viene el paso más conocido: multiplicar por el volumen.

Y el total del presupuesto es:

Estas ecuaciones sí son simples y suficientes.

Pero conviene decir algo que en la práctica se olvida mucho: el volumen no arregla una matriz mal hecha, no compensa un rendimiento mal capturado y no corrige un criterio inconsistente de sobrecostos. Solo multiplica.

Por eso un error pequeño por unidad se vuelve tan relevante cuando pasa al volumen total de la obra.

La explosión de insumos también es recursiva

La explosión de insumos no consiste solo en sumar materiales visibles. Su dificultad real está en desplegar toda la red de dependencias hasta llegar a insumos base.

Si definimos $R(i,x)$ como el requerimiento del insumo $i$ por unidad del nodo $x$, entonces puede describirse así:

Esta definición sí hace explícito el trabajo real:

• si el nodo ya es el insumo buscado, aporta una unidad;
• si es otro insumo base, no aporta nada;
• si es básico, hay que repartir el requerimiento entre sus componentes y seguir propagando.

Solo después de eso tiene sentido escribir el requerimiento total del insumo $i$:

Y entonces su importe consolidado es:

Ahora sí queda claro que la explosión no es una suma plana, sino una expansión completa de la estructura de matrices.

La verificación de consistencia sí sirve, pero no prueba todo

Hay una identidad útil que conviene conservar:

Dicho en palabras: la suma del importe de todos los insumos explotados debe coincidir con la suma de los costos directos por volumen en todo el presupuesto.

Prueba que la explosión es aritméticamente coherente con las matrices tal como están modeladas. No prueba que las matrices estén bien construidas en sentido técnico.

Un rendimiento mal interpretado, pero propagado de forma consistente, puede pasar esa prueba sin problema. Lo mismo una matriz conceptualmente equivocada pero algebraicamente cerrada.

O sea: verifica coherencia interna, no necesariamente corrección técnica.

Esa distinción importa mucho en la revisión real de presupuestos.

Que el archivo abra no significa que el presupuesto esté bien

Esto conviene decirlo sin suavizarlo.

Un presupuesto puede ser perfectamente legible y, aun así, estar mal construido.

• rendimientos capturados como si fueran cantidades directas;
• matrices con componentes incoherentes;
• auxiliares reutilizados fuera de contexto;
• conceptos con criterios distintos de sobrecosto;
• unidades aparentemente compatibles que no lo son del todo;
• o estructuras que cuadran en apariencia, pero no explican bien el costo.

Ese tipo de fallas no siempre aparece en el importe total. Muchas veces solo se descubre revisando matrices, siguiendo dependencias o contrastando la explosión consolidada con lo que debería estar ocurriendo.

Ahí está la diferencia entre abrir un presupuesto y revisarlo.

Por qué una herramienta así sí cambia el trabajo diario

La propuesta pública de presupuestos.red es sencilla: abrir presupuestos de OPUS y Neodata desde cualquier navegador, incluyendo Mac, Linux y celular; procesarlos localmente; consultar catálogo, matrices y explosión; y exportar a Excel. El sitio también deja claro que está pensado para revisar y consultar, no para sustituir las funciones avanzadas de edición, programa de obra o creación de propuestas desde cero del software original.

Traducido al trabajo real, eso resuelve fricciones muy concretas:

• te llega un respaldo y no tienes licencia,
• estás fuera de Windows,
• quieres revisar matrices antes de cotizar,
• necesitas validar una explosión,
• o simplemente quieres exportar rápido a Excel sin perder por completo la estructura.

Las guías del sitio lo plantean justo así para ambos casos: Neodata y OPUS. Incluso especifican compatibilidad con archivos de intercambio .zip, respaldos.bak, archivos .pu6 y proyectos completos en Neodata, así como.dbf de OPUS 2010 y .bak de OPUS 2011 a OPUS 25.

También señalan que el procesamiento ocurre en el navegador y que el archivo no sale del dispositivo.

Eso no sustituye a OPUS o Neodata cuando necesitas editar, rehacer análisis o usar funciones avanzadas. Pero para revisar, entender y discutir un presupuesto recibido, sí cambia de forma importante el punto de partida.

Lo valioso no es ver el archivo

Abrir un archivo sirve de poco si no puedes seguir la lógica que lo sostiene.

Lo valioso no es ver el presupuesto. Lo valioso es poder reconstruir cómo se compone, cómo se transforma y cómo se consolida. En otras palabras: poder leer no solo el resultado, sino el mecanismo.

Por eso un presupuesto de obra no está en los renglones. Los renglones son solo la salida visible de una estructura recursiva más profunda: insumos, matrices, rendimientos, factores y volúmenes.

Cuando puedes entrar a esa estructura, ya no solo tienes acceso al archivo. Tienes acceso, por fin, al presupuesto.